侵权与否这个要看有没有合法授权，有没有违反授权协议使用。至于是用官方安装盘安装的还是从网上下载的 Ghost 镜像安装的其实不重要，甚至不激活使用也不存在侵权。

OEM 预装的家庭版拿到企业商用仍然是侵权；使用非法手段获得的“正版”也仍然是盗版。

知识产品保护也并非只有好的一面，老是说这个就没意思了，就算是使用 Linux 桌面发行版也存在一些授权协议问题，典型的就是多媒体播放——虽然播放程序是开源的，但是媒体格式仍然是私有专利授权，为了规避授权协议问题，通常预置的解码库功能不完善，得用户自己安装。

总之，谴责他人之前先自省一下吧。

能做什么我不知道，不过最先做什么大概可以猜出来。

机器学习是建立在大量数据的结果之上的，有大量可靠的高质量数据对于模型训练是非常有用的。
考虑到这些数据的掌握者，更加智能的舆情管控，无论是需求力度还是技术能力讲，应该是会最先出现的。

虽然可以用 307 重定向，但是否可以成功还是取决于 client 的实现，这个是不可控的。

没必要。

自己先使用起来，提高自己的效率，偶尔在小组成员面前 show 几手，如果有组员表现出兴趣再来对他进行引导。
那些没兴趣的人就别自己找麻烦了，大把小公司都没版本控制，何况你一个大学小组。

@Kirikora 个人觉得对 Web 开发来说专注应用层性价比更高一些，当然有兴趣就随意了。
时间多个人推荐《 HTTP 权威指南》，时间有限可以看看《图解 HTTP 》。

说实话只要和 Web 相关的强烈建议先去看看 HTTP 协议的相关书籍或者 RFC。

域名在 Client 的作用是通过 DNS 解析到 Server 的 IP，但是请求需要在 Host 头中带上域名，实际请求还是发送到 IP 的。

举个例子：

GET /foo.php HTTP/1.1
Host: example.com
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*

基于这个过程有两种方法来解决：

第一：基于系统环境解决。

修改本地 Host、指定 DNS

第二：自己构造请求。

这种方法需要可以自定义请求的 Host 头，并且需要自己处理解析这块。可以选择硬编码 IP 或者还是采用第一种方法实现。

可以先使用硬编码 IP 的方式来尝试一下，剩下的就是要确认使用的请求库能否支持自定义 Host 头了。
如果想进一步解决硬编码 IP 的问题，那么就需要一个 DNS 的库来获得正确的解析记录，再来发起请求。

剩下的问题就可能出在 HTTPS 上，因为证书校验是需要靠域名校验的，client 处理的方式细节不同通过 IP 发起请求可能会出现证书校验错误，粗暴的方法就是无视证书错误。

有种手游论坛新人丢张 SSR 出来问 dalao 这个 SSR 好不好的即视感 :doge:

IO 方面会有差异，毕竟过了一层实现。

“没有银弹”虽然是说复杂工程没有简单的解决方法，但是也可以推断出，单一技术方法无法独立解决复杂工程的所有问题。

选择技术方案时肯定要考虑代价，但是各家业务都不同，不自己根据自身业务做个方案测试评估如何能拿出可以有说服力的数据？

难道写 V2EX 网友提供？

你以为开好车的就一定是好人吗？

以一个标签来判断对象的整体本身就是错误的，公司、学历、过往经历甚至性别、外貌，这些标签虽然能快速筛选减少成本，但是只相信这些标签就大错特错了。

全栈是个伪命题。

从企业角度看，如果公司业务都是集中在个别人员身上是风险极高的事情。从个人角度看，除了个别天才或者特别努力的人，大多数普通人是不可能做到全部都精通的。

创业公司初期时人员不足，有能“全干”的人员是效率非常高的，因为可以大大减少沟通成本，至于风险再高也没有创业行为本身的风险高；小公司则是需求的水平不高，在能用的前提，可以“全干”的人员即便离职也可以快速的通过招聘多个水平不高的人员补充——毕竟我国大学生可是大把。

不同公司的技术栈是不同的，“全栈”都是从公司角度的定义，所以业务不同的公司的定义肯定是不同的。

个人理解：从好的方面说全栈是熟悉各个技术的全能工程师；从坏的角度讲全栈是技术深度还广度还未够格的架构师。

DevOps 是一种理念或者说一种实践。

产品不是以开发完成作为结束，而是一直运行的，满足公司运营指标才是目的。在这种前提下，开发和运维的目的是相同的，所以不能隔离来看待。

CI、CD 平台工具、日志收集、批量运维工具这些都是为了这个目的而存在的。但是由于业务还有技术栈的不同，越大型的业务根据自身需要还有成本承受情况会选择改变运维方式或者自研平台 /工具。

无论如何选择，最终的目标都是追求产品运营运营指标。DevOps 作为岗位来看待的话，从某种角度说应该是“开发”，需要解决的“业务”则是产品如何更好的运营，DevOps 需要为解决“运维”效率开发各种工具、集成平台。

------

企业招聘肯定是想员工成为公司想要的人，但是对人个人来讲应该以自身发展、兴趣爱好为首要。因为我国处于并将长期处于社会主义初级阶段，养老不能只靠政府，更没可能靠企业 :doge:。

有长期目标是好的，但是目标越远与企业的预期偏差就越大，话说得太尽就没有余地，楼主虽然年龄不小但是阅历还是少了点。

通常这样做的目的是为了分页，实际阿里的 pgsql adb 德哥有专门发过一篇博客吐槽这个

http://blog.163.com/digoal@126/blog/static/1638770402016468349463

实际上根据业务情况也有一些不用 count 的方法来解决这个问题

https://stackoverflow.com/questions/109232/what-is-the-best-way-to-paginate-results-in-sql-server

浏览器也是 HTTP client，证书校验只是通讯时的机制，只要是符合规范的 HTTP client 都能支持。证书也不一定保存在系统，client 也可以独立处理。

申请仲裁的时候就申请不接受调解，可以有效减少被拖的时间。

@xieweizhi007 你们没有选择了，即便对方开出撤销仲裁就给开离职证明的条件。一旦撤销仲裁，怎么保证他给你开这个离职证明？选择相信一个骗过你们的人？

法律只是定义违反规则的“成本”。劳动纠纷这种，劳动者不去争取，违法者就不用付出“成本”，从这个角度讲，老板可不是法盲。

3、最多可能拖你两年，最少半年，你仲裁没意义。

走完仲裁才能走起诉，仲裁可以拖至少 60 天，然后起诉完还有执行，总的来说确实是最少半年。

不过，既然都请律师过来专门说仲裁没意义，那就是说只有仲裁走到底才有效果了，不然也不会专门过来说。

4、必要时老板会关闭公司。

公司注销是有前提的，不是说注销就能注销的，有法律纠纷的话是注销不了的。

总的来说，如果不坚持走完仲裁就毫无意义，说白了就是吃准了你们走仲裁的机会成本高。但是不走仲裁对公司造成不了任何威胁。

另外，如果一家公司因为劳动者与上家公司因为不发薪水产生纠纷而不接受入职，我觉得也没啥必要入职了。

虽然 DevOps 看起来很美好，不过小公司根本不需要，业务规模小，让后台开发兼职人肉运维就行了。可以看看现在招后台的都会带点运维技术要求——美其名曰：全栈（ gan ）。

大公司 DevOps 的技术栈要求就跟后端差不多，而且广度还更高，加上需求又是和自身业务息息相关的，直接从开发人员抽调或许更实际一些。

内核开发，到不是没用，不过以现有成熟工具链、技术栈提供整体效率比开发内核这种方式收益大得多。

DevOps 的经验问题就是个伪命题，上个月找了家初级 DevOps 岗位，HR 在电话里说最好有管理上千台服务器的经验。我直接回了句：如果在这个业务规模的公司做过的人，恐怕看不上这个岗位。然后，就没有然后了。

运维是个技术越发展需要的人越少的职位，完全的 DevOps 大概被消灭的就是 Ops 了，初级职位真心难找。或许，只有那些方案集成商或者外包公司才能找一些初级 DevOps 岗位。

我觉得楼主还是学前端吧，Python 给人感觉牛逼哄哄啥都能干，但是偏偏工作难找。现在好多前端工程化都不会的前端照样活得不错（不是黑），初级工作也好找一些。

年龄大的套路见得多了不好忽悠，HR 和老板都不喜欢。

楼主应该开个二手树莓派交易群，人应该更多。

对于服务端和中间人来说没有区别，所谓的 URL 在地址栏这是客户端自己的实现，跟 HTTP 协议无关。
URL 长度 HTTP 协议中也没有规定，但是受客户端和服务端实现影响，不同的应用可能限制不同，或者可以配置范围不同。