没啥, 我现在也在创业阶段, 多找几个人, 共担风险

需要多穿点, 很冷. 准备个手机(可以联网的那种), 带好数据桥接线, 方便联网安装, 某些环境, 机房是没有外网的, 有外网也容易残缺, 很多网站被屏蔽了.

C 非常简单, 如果你有 Java 的基础, 你只需要理解 2 个概念, 指针(可运行,可操控不安全的引用), 内存堆栈布局结构. 作为一门语言的 C 是简单,简洁,且强大的, CS 基础的任何一门基础课程使用 C 都足够完成任务, Java,C#这种, 主要是为了工程和理解另外一个重要概念而准备的(强类型, 类型结构显示定义), 等你打好基础后, 你发现你还至少需要学 1-2 种面向对象, 1-2 种函数式, 或者一些四不像, 混杂了多种编程范式的语言, 然后需要训练工程能力, 再然后是架构能力或者去做基础设施, 就不需要搞这些应用层的东西了.
最重要的一点: 技术并不值钱, 值钱的是你使用技术解决了某个特定领域有价值的问题, 所以你最终会发现, 业务领域才是一个巨大的天坑, 每一个小领域都需要耗费大多数人一辈子
@Poluk

我尝试过使用 Java 和 C#, Python 写过这种基础的东西, 最终发现, 某些细节只有在 C 这种语法糖特别少的语言上才能理解的透彻, 虽然初期痛苦, 而且代码冗长, 但有助于你从基础的东西向上走, 或者向下走到汇编, 机器码

先学数据结构, 然后将最简单的常用的 20 种左右的排序写一遍, 查找写一遍, 遍历(树,图)写一遍, 然后计算机组成原理和算法入门可以并行, 不要用 Java, 尝试用 C 语言, 如果你的目的是学习原理和理解后面的计算机组成原理, 操作系统, 编译原理. 如果是学习计算机科学(注意是学习), 基础的分支, 循环就够了, 不要在意那些为工程而添加的语法结构. 等你要去做项目的时候, 在尝试去寻找对应语言的库的 API

4 个台式机, 一个笔记本, 从升级到 Windows 11 后, 从未蓝过, 就是资源管理器的 BUG 有点多!

这个问题已经争论了无数次, 没有什么是好的或者坏的, 保持一致性最重要, 我记得<<.NET 设计规范>>有一章节专门讨论过这个问题, 结论是: 一致性最重要

找个车道级别的导航, 注意自己的所在的车道, 随时观察路标, 确定自己要直行还是转弯, 提前变好道, 最主要的还是先开熟路, 慢慢的, 对车辆的操控感好了, 不紧张了, 在路上就可以随时变道, 加塞(注意违章拍照), 游戏我觉得用处不大, 我也一直耍赛车游戏, 但最初开车还是非常菜, 有模拟方向盘那一套应该会有点用处.

给你个关键字, 自己搜索: 7 级累计超额税率

@kokutou 电脑性能很好, 不是啥问题, 不管是硬件还是显卡

@liberize rtsp 是没戏,我刚刚才搞明白, flv 和 hls 的延迟是必然的, 所以问题基本无解. 我先用 wasml 用 ffmpeg 做个软解 HEVC 的凑合一下, 检测到 H264 就直接使用 hls.js, 先做个凑合的方案, 可以加个微信或者其它联系方式交流下心得吗? 有偿咨询也可以的

@kirile 我有 2 个监控平台(海康和大华), 卡在了大华的 H265 上, WebSocket 大华木有, 而且他们的视频全是 HEVC 的, 所以头痛

@siguretto 这个方案行不通(商务上行不通), 没办法, 最初的时候我就是这样考虑的, 这个方案我之前用过, 现在是商业合同卡死了必须是 B/S 架构, 但我们合同中有说到, 需要使用最新浏览器, 因为我们需要现代浏览器提供的高级 API, WebGL, WebSocket, WebLock 等. 我正在研究一个 GitHub 的项目, 找了个海康和大华的摄像头, 周末试一下, 看能不能跑通

浏览器不是问题, 可以指定非常新的浏览器, 但不能指定 IE 这种, 甚至可以只兼容最新版本的浏览器, 我现在考虑的实现方式是使用 WebAssembly, WebWork, 然后 Canvas, 硬画, 我研究了下 Bilibili 的播放器实现, 似乎 H265 也是这样用 wasm 做的, 我们的用户量很小, 并发不会超过 100 个, 客户的客户端很强到, 可以理解为高配工作站(因为要上大屏), H264 检测到 hls.js 和 flv.js 都可以, 延迟暂时还不是一个强需求, 但 H265 必须支持, 因为所有摄像头的预览和监控的编码都是 H265, 只有极少部分是 H264, 客户不愿意改码流, 海康的人也不愿意担责, 所以只能想办法解 H265

flv.js 和 hls.js 都不支持 H265

直接 2720QM, 我用的就是, 没有任何问题, 笔记本连接 90W 供电, 就是做工有点差!

VSCode 能做起来, 是因为他选择对了路, 也是唯一的一条路. 未来相当长一段时间如果开发模式没有本质变革, 没有人能挑战它了.TypeScript,nodeJS, Chrome 三者几乎都是未来工业化 WebIDE 的基石了, WebAssemlby 还太嫩了

这种基于词法,句法的分析器, 如果某个词法解析失败了, 后面的解析也无法进行, 因为编辑器无法为后面的代码创建一个有效的 Context(其实是编辑器不够智能,哈哈), delete 肯定是不能够做函数名称的, 从 C 继承而来的运算符关键字