V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  maizero  ›  全部回复第 11 页 / 共 86 页
回复总数  1710
1 ... 7  8  9  10  11  12  13  14  15  16 ... 86  
224 天前
回复了 sonnyclarity492 创建的主题 程序员 当下你是如何保护隐私的?
如果使用社会化公众服务(主要指数字化生活),不涉及到必须提供真实的个人信息的,我认为一些保护手段(通过端上的努力)是有意义的。
包括:不同社交媒体、APP 的账号差异化、鉴别信息差异化、分类分级、减少追踪、尽可能数据本地化等等。

如果是用的是必须提供真实身份,例如实名制认证、真实手机号码和地址,那么个人做的再多努力,可能也会因为提供服务的一方不作为、恶劣作为(缺乏保护意识、保护能力差,甚至主动侵犯),毫无作用。

我们可以做的是尽量做到 1 ,尽量减少 2 (不影响生活和便利性的情况下)。

也看到一些大头厂商通过隐私号码的方式做出努力,但有待强制推广。
224 天前
回复了 sonnyclarity492 创建的主题 程序员 当下你是如何保护隐私的?
尽管我在上面留下对隐私保护的悲观,但我仍然认为我们应该不放弃保护隐私的努力。
我 2020 年开始从事隐私保护合规的工作,先从 GDPR 开始,然后开始覆盖到海外各国,包括美国陆续出台隐私法的各州,以及关注联邦层面的动态。
还有东南亚国家、日韩。
最近负责国内合规工作,再次研究个保法、工信和网信在 APP 上对个人信息采集的监管规定。
从立法、执法的动态上,这个环境是向好的。
各国(包括我国)都在用大力气治理隐私侵犯。
因为这个隐私侵犯已经不是一个普通的个例,已经是各大商业巨头都在名正言顺的做的事情。
这就很可怕。
为什么悲观是因为作为个体,我们无法拜托社会服务。
尽管百度的李彦宏被喷,被淋水,但是他只是讲出了一个事实、现状。
“现代人为了享受数字时代生活的便利,不得不度让一部分隐私”
当你要用公众服务的时候,对你的隐私侵犯就已经开始。
我们是社会人,无法绝对摆脱社会服务。
特别是国内有实名制的要求,这个无疑对隐私泄露对个人真实身份的关联、影响变得更严重。
网络身份可以更换,数字移民也可以,但是只要摆脱不了实名制的社会化服务——特别是 g0v 提供的服务。
你就脱离不开这个魔咒。
225 天前
回复了 sonnyclarity492 创建的主题 程序员 当下你是如何保护隐私的?
从业十几年,接触的真相越多,感觉个人越无能为力。
苹果用了很多努力,但你也经不住 APP 自身的超范围采集、滥用。
隐私政策更多是一个遮羞布,甚至遮都不遮了。
有厂商的主观故意,也有无能导致被脱裤。
TG 上多了,就知道随便开盒太简单。
连明星也不能例外,平凡人更加。
不敢轻易得罪人,一不小心你整个户口本都被人爆……
诶。
现在立法是跟进了,只求监管继续加强吧。
想入 iPhone 15 Pro Max ,苦 L 口已久,换 C 口和升级长焦是最大动力,10G 的有线速率虽然没用上雷电但比 USB 2 的 480M 要好很多,iCloud 上 2020 年到现在已经超过 500G 的照片(还是去掉视频的情况下),所以想买 1TB 版本,看到和 256G 的差价是 4000 ,看到别人说 768G 居然要 4000 ,太黑了,就想着是否要考虑 256G 的版本。
但想来想去,自己的诉求是希望 iPhone 拍的多年的照片和视频,都在设备本地查看,还是考虑 1TB 版本吧。
于是为了自我安慰,换了个算法……
1 、把 iPhone 当成一个整体;
2 、用价格除以容量:
iPhone 15 Pro Max 256 GB 9999 39.0625
iPhone 15 Pro Max 512 GB 11999 23.4375
iPhone 15 Pro Max 1 TB 13999 11.627906976744185
然后就开心了……

ps:仅供娱乐,勿喷
抱歉抱歉,昨天遇到问题了没过脑子直接就发了,然后转身就忙去了。
后来仔细看了下报错信息,的确是 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
UTM 官方的帮助文档就有写,应该是版本过低不支持。
当时觉得奇怪的就是到了格式化磁盘后 copy 文件这一步才报错就很莫名其妙。
今天换 WIN11 ARM 最新版本,官方下的磁盘镜像,在 MAC 上安装卡最后一步要网络,还没整明白。
图啥,好玩呗,我又不缺设备……
我看着还以为是反串 结果…… 那我求一个建议 有什么产品质量和售后体验更优秀的推荐呢?
@dudusprinkler 没必要 默认就好
对了 SN640 全新 5 年国行支持个人送保的 才 1699
@mlyxdev 你怎么知道我放弃了用 NUC 当存储方案的? 这个帖子似乎我没提过,好奇……
之前考虑 NUC9 是因为带 2 个 PCIE 卡槽( X16 X4 ),还带 3 个 M.2 接口,2 个 22110,1 个 2280 ,还带一个 SATA 接口(需要转接线),但 NUC9 本身是紧凑型的小机箱,别说塞 U.2 了,哪怕塞满 3 根 M.2 ,都很热,我后期有塞 2 根 22110 4T 的三星企业盘,自带散热的情况下,温度到 67 度; 如果考虑在 PCIE 卡槽塞 U.2 ,那会更热;
另外你提到的功耗也是个问题,之前我是 QNAP 8 盘位 NAS ,HDD 很吵,但是当时没考虑过功耗问题,后来就考虑功耗+噪音了; NUC9 的功耗在 50W 左右,如果有负载会上到 100W 左右吧; 如果只是当 7X24 小时的 NAS ,这个有点不划算; 目前我是用一个 MATX 的机器+大机箱+2 个 U.2 和 6 个 SATA SSD ,如果不考虑万兆网卡以及阵列卡的需求,单纯当全闪 NAS 的话,还可以塞更多,发热不是问题、声音也不是问题了,这套机器我用了 ES 的 U ,目前这样跑功耗大概整体在 50W ,跑了 EXSI ,一堆的 VM 。

你还是考虑清楚数据备份还是需要在线的 NAS ,盘的功耗官网指标有写,我不是很在意对比。
主要是反光这个区别 不对比不知道 对比了后就很不舒服
265 天前
回复了 snowstorm666 创建的主题 macOS 现在想入手 macmini 合适吗?
合适
28xx 的 M2
272 天前
回复了 zetaochen 创建的主题 Apple 大佬们 mbp 键盘 都有贴膜吗
每一台 Mac 都贴,不为保护,只为好看。
273 天前
回复了 gregy 创建的主题 云计算 求助大容量云备份方案
另外,如果量真的那么大,又都是冷备需求,为什么不考虑买个磁带机呢? LTO6 或者 7 都可以,6 性价比比较高。
磁带的存储只要做好干燥,也很好保存,定期备份后邮寄到某地(连干燥箱一起)就好了啊。
273 天前
回复了 gregy 创建的主题 云计算 求助大容量云备份方案
@gregy #64 理解你的顾虑
虽然我也是家里有 PB 级存储的人,但真正重要的数据,不超过 8T ,一个 U2 就能塞下
所以 TO C 的网盘对我是绰绰有余了
通过 NAS 的备份功能,备份到 TO C 的百度云、阿里云盘,或者 S3 / OSS 都够,当然秘钥要保管好

我是严格实践数据保护 321 原则的人
甚至高于 321 原则

本地多副本(超过 3 ),不同的介质,冗余和备份,随身的、在公司的、云上的、异地老家的
因为量小 所以没你那么多烦恼

100T 的重要数据……有点夸张
因为我认为数据治理的前提是分类分级
真正需要那么夸张的解决方案的,一定是金字塔最上面的部分
274 天前
回复了 gregy 创建的主题 云计算 求助大容量云备份方案
6 、HDD+盘柜+硬件阵列卡+低功耗机头+网络,自建都比云的方案靠谱……
274 天前
回复了 gregy 创建的主题 云计算 求助大容量云备份方案
1 、免费/低价的产品,不可靠;
2 、TO C 的产品,面对 100T 的容量,也不太可靠,厂商随时变更协议;
3 、考虑商业化的 OSS 、S3 比较靠谱,TO B 的存储,如果不可靠,那么云厂商不用开门了;其中冷存储已经是最便宜的方案了;
4 、不知道为什么一定用云存储,从 OP 场景,压缩再备份,那么访问需求不大,为什么不做本地冷备、多副本?
LTO 磁带,或者简单点二手 HDD ,都很容易解决;
5 、100T 其实不大,针对本地来说,因为我本地的数据懂不懂是 PB 级别的,一堆 HDD+异地,就搞定了……
274 天前
回复了 810975 创建的主题 问与答 大家开车通勤会很烦躁吗。
我不喜欢开车,虽然通勤时间 15~20 分钟,路上也遇到很多龟速、加塞的。
我只能尽量让自己开心点吧。
音箱搞好点,开车佛系点。
1 ... 7  8  9  10  11  12  13  14  15  16 ... 86  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2123 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 15:59 · PVG 23:59 · LAX 08:59 · JFK 11:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.