似乎当今市场上的大多数电缆调制解调器都是 DOCSIS 3.0 ( ex )。
然而,“最近”(2013 年)发布了DOCSIS 3.1。
我假设(可能是错误的)到目前为止,找到 DOCSIS 3.1 电缆调制解调器要么很难,要么更贵,因为大多数流行的调制解调器似乎都是 3.0。因此,出现了 3.0 是否“足够好”或者我是否应该为想要 3.1 而烦恼的问题。
对于普通 Internet 用户而言,拥有 DOCSIS 3.1 电缆调制解调器与 3.0 相比有哪些切实的好处?
有助于缩小问题范围的说明:
我试图弄清楚为什么当从安装在 SAMBA 的 Unix 分区上的 Windows 编辑器保存的文件的权限更改时,会出现特定行为。
情况:
我们在 Unix 上有一个文件,具有 777 权限:
-rwxrwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*
文件所在的目录是通过 Samba 从 Windows 7 PC 挂载的。
我们在“Notepad++”或“Sublime”编辑器中打开文件进行编辑。
更改并保存文件后,在 unix 端,权限更改为:
-rw-rwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*
现在,我怀疑这可能不是由于 Samba 挂载,因为在常规 Windows 记事本中打开和保存文件时不会发生同样的问题!
因此,我最初的想法是,这是因为上面提到的编程编辑器可能会被设置为 - 而不是简单地保存文件 - 将原始文件重命名为$orig_filename.bak
,然后将新内容保存为具有原始文件名的 NEW 文件。这是基于我自己之前使用 UltraEdit 编辑器解决相同问题的经验。
但是,如果这是烫发变化的原因,我无法解释我观察到的两个其他症状:
首先,首先没有创建备份文件。
其次,touch
在 Unix Shell 的同一目录中创建新文件(使用)时,新文件的权限根本不是-rw-rwxrwx
。
第三,如果重要的话,文件的 inode # 在编辑后保持不变。
还有什么可能是问题,我可以采取哪些步骤来调查它?
当我告诉 UE 不要通过重命名备份文件时,我自己的 UltraEdit 问题就消失了;但是 …
在 Firefox(Windows,最新版本 50+)中,有没有办法对其进行配置,以便在阅读器视图中自动打开特定站点的页面?
Firefox 的 Reader View 帮助页面没有产生任何结果。
请注意:我要求自动切换到读者视图(而不是像这个问题那样手动切换);并且该问题假设给定站点完全支持阅读器视图,因此每个页面都已经具有可用的视图图标)。
我的 Firefox(Windows 10 上的 Quantum v.66)崩溃了,我不小心点击了“开始新会话”而不是“恢复会话”,这丢失了我以前的所有选项卡。
好消息:在我的个人资料中的“sessionstore-backups”文件夹中,我发现了一个名为 previous.jsonlz4 的大文件,它似乎包含我以前的所有选项卡和窗口。
我使用Firefox 工具的 Session History Scrounger确认这是一个有效的文件,该工具似乎是我在谷歌搜索中找到的关于该主题的唯一有用资源。
坏消息:经过几天的谷歌搜索,我似乎无法弄清楚如何将数据从 jsonlz4 文件恢复到浏览器的选项卡(基本上,将其恢复为崩溃会话恢复)。
我尝试过的:
将该 jsonlz4 复制到“sessionrestore-backups”目录中作为“recovery.jsonlz4” - 根据我的实验,这似乎是 FF 崩溃时更新的文件。这没有效果。
将 Scrounger 为我创建的 JS 文件复制到 previous.js 和 recovery.js 中。没有效果。
删除了我的个人资料中“crashes”子目录中的“store.json.mozlz4”文件。没有效果。
笔记:
注意:我并不是在寻找随机方法来从 Scrounger 创建的 JS 文件中获取 URL 列表。我知道该怎么做。我想将崩溃的会话实际导入到 FireFox 中的崩溃会话恢复中,或导入到活动的 Firefox 会话中。
注意:我知道这个类似的问题,但它询问 2012 年左右的 pre-version-57 会话格式,这似乎与现代 post-version-57 会话机制无关。
我看到经常提到,将页面文件放在固态硬盘性能但不适合SSD的寿命好(如这里的SU)。但是我所看到的没有任何引用,尤其是有实际数据支持的引用。
是否有任何合理的测量支持非轶事评估对 SSD 寿命的确切影响是什么?
例如,它会导致 SSD 在 1 年内出现 50% 的故障,还是将其从平均 5 年缩短到平均 4 年等等...