V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 1 页 / 共 77 页
回复总数  1526
1  2  3  4  5  6  7  8  9  10 ... 77  
2 天前
回复了 willx12123 创建的主题 程序员 如何使用 Windows 愉快的编程?
@walpurgis WSL 不是这个原因而产生的,它的前身是意图在 Windows 上原生运行 Android app ,但因为种种原因黄了(很久之后 Win11 上 WOA 才被支持)。
反过来,用你的逻辑,也说不通为什么微软仍然花更大的力气支持 VS (不是 VSC )这种根本就是 Windows-only 的开发环境——注意是持续投入资源推动大量的功能性更新,而不仅仅是维持可用。
2 天前
回复了 willx12123 创建的主题 程序员 如何使用 Windows 愉快的编程?
可以默认用 WSL 。
嫌弃虚拟机麻烦(比如 IP 地址莫名其妙啦……),就 WSL1 ( WSL2 本质就是个 HyperV 虚拟机实例),虽然有些限制,大多数还算能用。
例外情形:
若你需要开发 Linux 内核模块本机调试之类,那当然没办法;
用 fuse 之类也可能比较麻烦;
偶尔会有些系统调用实现残缺不可用;
不要指望 systemd 之类的东西完整可用(同等层次上依赖系统实现细节的还有 nix 等);
GUI 多少比原生 Win32 麻烦且可能有无解的细节问题(例如输入法之类),性能可能也不咋地( WSLg 需要 Win11+WSL2 ),但 VcXsrv 跑个别应用基本上够用;
其它情况下,和原生 Linux 的差异是否能被容忍,取决于你自身对环境的理解(觉得不保险嫌弃麻烦那还是虚拟机了)。

如果要更原生的体验,用 MSYS2+MinGW 。
警告(相对 WSL ):原生 Win32 的构建性能会普遍降低;
小文件 I/O 性能会极其感人;
即便排除 I/O 问题,也不要指望 node.js 之类的运行时的表现不会明显变差;
同时,可能处理一些表面上容易遗漏,实际 Win32 特有的屑问题,大多是关于文件系统的:
Win32 的默认机制导致打开程序不能删除,这有时候很欠揍;
默认创建符号链接可能需要管理员权限,需要组策略变通;
Win32 不支持无视 AUX 这样的 DOS 保留文件名(但 MSYS 的工具能提供一些变通);
可能必须需要 fsutil 单独设置大小写兼容。

如果你要继续完全原生地使用 Win32 ,那么基本不会有更好的体验(以上 WSL 解决了的 Win32 问题会继续存在),并且有些问题是无解的。

@cmdOptionKana 这篇文章有些是很扯蛋的,或者至少是过时了(即便考虑原文时间无视 WSL )。

像工具方面:
很多都是 Win32 自己残废,而不是命令行;
Win32 的残废如果不是需要自己积极变通,是可以改用现有工具在 Windows 上的移植而无视的;
如 git 的不好用,大多是因为 git 自身而不是 Windows 上的实现(除了一些 I/O 性能问题)。

在如,第五点几乎全是在 FUD ,不知道是在黑 Windows 还是黑 Linux 。
你需要 hg incoming 类似的东西?
逻辑上还是少不了类似 fetch 的下载一些元数据的步骤,不过在明确只考虑这类需求(而不必然是之后紧接着会 fetch )时,确实至少会比 fetch 节约流量和带宽。
但是 2202 了,git 连 clone 的断点续传都不兹瓷,大约你也不需要指望这种东西了。
2 天前
回复了 opentrade 创建的主题 程序员 Rust 桌面程序选 Flutter 还是 Tauri?
我没法给出可靠的具体建议,不过需要指出,光是想搞清楚什么算是“前”,对 GUI 开发者来讲都经常算是不切实际的奢望。从现状看,“过时”在这个领域中不应该是需要被优先考虑的缺陷(否则很容易发现新的都是一出生就更过时的)。
cf. https://v2ex.com/t/852363#r_11667402
2 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
目的上……现状大致如此。如 vscode 这样的编辑器,其实用浏览器代替,也不会比 ssh 过去再用麻烦(即便编辑本地文件逻辑上比较感人)。
创业公司实际比较不好说,在 Electron 能胜任的前提下,选型主要倒不如看老板 /CTO 是不是有前端背景。如果直接有整个前端团队那么也还算是很香的(但是也别指望能做到 vscode 的程度)。

另外,我始终认为有必要把 C++/Rust 这些和所有有 GC 的方案区分,不是因为 C++之类的难度如何,而是默认情形的正确性——很大程度上,写 GUI 基本就是从头开始写 bug 。
有 GC 的语言实际上是假定资源默认推迟而没有可观察行为,这对 GUI 根本矛盾,因为 GUI 最基本的需求之一是对响应有要求(应用级的实时性),而程序内部却默认对此几乎完全放弃保证。一些像基于.NET 少数做的还能看的方案,是在框架层次上就死命优化和工具等周边生态配合的结果;相比之下,Electron 之类(浏览器实现)就无能为力或者干脆弃疗,锅都甩应用开发上了。即便是.NET 的程度,还是在鼓励默认和根本需求相违背的写法。
实际上 C++也算不上好哪去,因为 C++同样没能力显式区分描述可观察行为(无非是多了个 volatile ,没有 effect handler 之类),同样没有强制实时性的原生支持,实质上也缺少鼓励异步的写法(新手基本是写出来发现交互寄了点不动,才回去改),因此同样免不了在运行时外面套壳(指应用卡翔以后系统给出无响应界面替代而不是继续阻塞)。只是没默认 GC ,而是要求用户自己在详细设计时搞清楚所有权关系,避免默认就写出看上去顶用但实际就是一坨原生 bug 的玩意儿,已经相对算是进步了(反过来说,直接用默认 GC 的语言写 GUI ,就是明确的退步)。
照例继续多黑弃疗党的代表一下:github.com/dart-lang/language/issues/490
……看到这标题一瞬反应是 BABA 股价咋那么高了(笑哭.jpg )
3 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@learningman 1. 不要看古董和野鸡教材误导浪费时间,就开发个普通的 GUI ,C++有的那些烂门槛,实际怕还不如 Qt 的非标准工具搞出来的破事多。
你倒不如说 C++开发 UI 效率整体还是低。这个尽管近些年有改善,但从没彻底解决;想跟前端比差远了。
2. Qt 的平台特定的代码,一部分是故意的(因为不是每个平台都能支持相同的功能),少部分是太旮旯,少人关心。
相比之下 Electron 更统一,但是真需要平台特定的功能,基本全部要你自己搞定。所以这个比较不公平。
不过这部分的选型问题我中立,因为 Qt 的 C++用起来算是比较恶心的,UI 以外的部分都不见得比无视 Qt ,全部自己搞定方便,所以没明显优势。
3. 那按上面我提的,当我没说。
4. 这有点强词夺理。即便是依赖 Qt 的应用,也可以要用户自己源码编译或者可以自带二进制文件,但为什么非得费力不讨好?体验明显差。
注意 Qt 的二进制文件基本上是 native 方案里最大的、跟部署个浏览器没差多少、基本上同样被鄙视的那类(特别是 Windows 上基础设施支持薄弱,装了也很难复用,到处复制 dll 算是传统艺能了),与其说兼容性,还不如说是在安装体验上拉到了几乎跟自带浏览器的应用同等低劣的水平,这点更容易让用户感知到。
就算硬盘空间不值钱,流量和用户的时间仍然经常比你想象中的更值钱。
Electron 在这里选择余地更少所以仍然更差。

@encro 大部分“桌面”应用,指的是传统上 UI 和功能集合在一个软件产品的应用。即便如此,有的(如 Office )也在往 Web 跑,回到桌面(至少在现有桌面开发体验极大改善前)不是主要趋势。
如果一个产品的服务端的重要性占比例太大并且 Web 实现够用,那么其实并不太有提供桌面客户端的需要。毕竟桌面浏览器现在整体能做到的比移动端强得多,用户习惯也普遍不一样,犯不着非得单独多给个 app 加深粘性。
既然已经部署成云服务了,顺手能写个 Web 的,干嘛非得再多此一举呢?多少有些凑 KPI 的味道了。
4 天前
回复了 rockyliang 创建的主题 程序员 关于 git 协作的一个问题
这看来是详细设计评审没做到位,或者根本就没怎么做。如果小明和小红清楚地知道对方在干啥,这种共用函数一般不会是实现了一半才发现,要么就是发现了也少到能容忍复制粘贴实现的程度。(还有种情况:A 和 B 大到设计时没法一次性做到那么细,直接扔给单人负责却又不及时同步以至于根本没法及时注意到别人做了啥,但那样是项目计划就离谱了。)
正常做法是知道共用函数后开 upstream feature branch 或者并行开 common feature branch (极端情况下嫌弃 feature 少 branch 多也可以扔 master 里,如果项目规则允许)优先实现,然后直接基于这个 branch 或者包含这个 branch 修订的某个 tag 开 A 和 B branch 。
但既然开发了一半,如果不像停工重建这个流程的话,就 cherry-pick+rebase 补救吧。是不是 squash 看约定,改动太大可能会很麻烦。
4 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@encro 个别应用用 Electron 可以,带上桌面环境或者大型 GUI 应用的,Electron 基本没戏,并且不大会随着时间推移而改善——这是我先前表明的基本观点。

其实桌面跨平台开发的问题挺经的了,包括 Electron 和 Qt 在内的话题讨论过很多次。在 v2ex.com/t/841554#r_11485005 这里就有很多细节。

老实说,Qt 的问题其实非常大,纯属矮子里拔高个。关键是如果想要跨平台,就没几个选择。Qt 是现有 GUI 框架方案中功能、性能、工具、社区支持、案例资源……等方面整体均衡考虑下最完善成熟的一个。虽然设计有很多挑战忍耐力的小问题,成本也算不上很低,但是并没有像 Electron 那么显著、容易在一大类项目中一票否决的缺陷(像上面讨论的问题中 OP 直接就不接受 Electron );也没有贸然采用不那么流行的新的方案的风险。

基本上现实会考虑 Electron 的主要是两类:从现有前端项目迁移;有相对比较多的前端开发人员,但是别的人员不充裕。其它情况,Electron 很难成为首选项。特别地,想要完全解决各种没法预期的问题,和自己维护一整个浏览器的技术难度差不太多,不像其它很多方案实在不行自己魔改一下也行。相对改浏览器运行时,C++的原生框架就算需要魔改定制,都不算多困难了。

Qt 不是不能用样式,QML 这种照抄前端的方案直接就能 CSS 定制。不过我个人对那套不太感冒(开发体验也不会有 Web 成熟)。
MVVM 不是万金油,特别是有一部分典型的桌面应用不那么合适。若干年前微软发明 MVVM 的就写过一些技术文章讨论里面的缺陷,记得大致意思是比 MVC/MVP 等都更重量级,性能必须有损失(当然比起 Electron 、Flutter 之流嘛基本可以忽略),而好处基本体现不出来。不过这是相对比较细节的问题。Qt 在这个架构模式这个层次上的设计也确实不咋地(相对 WPF 等),而且要真用上 MVVM ,(就 Qt 框架设计者的 C++水平看)怕是出来的 API 只会更难看和难用。
Python 绑定用起来是一时爽,但如果要自己重现里面的技术,做框架级别的开发就蛋疼了。(最近几个月我还在头疼怎么搞出个类似 Shiboken 的东西,同时避免对 Python 的依赖。)

(其实我是有本事手糊跨平台框架,但是我没本事保证足够的人力出完善的解决方案,所以就忍了。)

其它技术,像 GTK+和 wx 这样同属 native 的,资源比 Qt 缩水多了(也许一般开发者体验到的最大的好处就仅仅是不用 Qt 恶心的 C++ moc )。而像 Flutter 之类基于动态 GC 语言的框架,大多类似 Electron ,根本上不能指望克服类似的缺陷,并且显然还没 Electron 资源丰富。
微软的一些东西做得相对中庸一点,但你没法确保啥时候微软自己怂了就跟 WPF 一样丢下转进跑路了,留下社区收拾不了的鸡肋烂摊子。再者,Windows 自己 GUI 风格带着开发体验碎片了一地,也很难让现在的桌面开发者对微软重拾信心。并且像 WinUI 这种直接扔下旧版 Windows 不管的作风(明明就算加个支持也不是很难就是不干),很多传统开发者是不买账的。
所以我不觉得这些方案有更大的发展空间能一桶浆糊。
考虑这些新的方案就没有一个打算(能不能先另说)同时解决以前的主要痛点,反倒要超额投入精力才能熟练,学到的东西复用还困难,这也太微软了。因此,在具体刚需前没什么上车的必要。
4 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@learningman 牛头不对马嘴……你看看你在这里的几个回复有几个是正面回答了他人对你的说法的疑问的?
我对“企业级”什么的就没兴趣(高性能?要不是欺负的是 Electron ,啊呸……),你看看你说的是个啥?
承认 Electron 在桌面基本没生态(除非你好意思把 Web 硬是直接算成 Electron ),偶尔有个能的应用基本都是自带运行时而没有现成的系统基础设施的广泛支持,有这么难么?

所谓“从其他平台迁移”,你这个其他平台,不就是 Web ?要是有不兼容的 native 组件需要移植,也和 Electron 自己没什么关系,不管是优点还是缺点。当然你非得把一个系统上的 Electron 当作一个平台如蜜传如蜜,那当我没说。

相对地,一大票 Qt 软件直接就是原生开发好的,一样不用迁移,无非是重新构建一次,一样能做到所谓的几乎 0 成本。区别只是 Qt 故意开发不可移植的应用仍然更容易。但就这里的问题,本来用 Qt 就是为了跨平台,谁那么空哪壶不开提哪壶?所以你说的还是莫名其妙。
5 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@encro 基本上多数人都会考虑的上规模的,也就一个死命优化的 vscode 还能看了,即便如此也只是能用,并不相对非 Electron 实现的竞品比起来明确占优势。没那么上进的同类货色……比如看看 Atom ,坟头草多高了?
倒不是看不上 Electron ,说实话里面的黑科技还是挺多的。
然鹅 Electron 自身的技术弱点决定了要实现能实用的规模产品,必须投入巨量的资源,而且撑死也就是“比较能用”的范畴。所以除了迁移 Web 应用,对大多数开发者基本也只适合试验做原型。而做原型的选择未来也只会更多,固有问题解决又极其困难,所以注定前景不会好哪去。

@XiLingHost Unity 在跨桌面这个坎上不成气候。
真算上,那么跨 Windows 桌面和 XBox 呢……是一个概念么。

@learningman 别的小儿科不提,Qt 有被拿来实现 KDE ,Electron 有个啥同等的玩意儿呢?
或者你更愿意嗦 GTK+?
5 天前
回复了 Joker123456789 创建的主题 Java 关于 Java 很啰嗦的问题
半斤八两?你直说吧,就是欺负人家在有选择的前提下懒得写啰嗦业务代码罢了。真写得写不出来明显两码事好不。
比如就实现操作系统这个业务,真有人汇编写出来比你 C 写得啰嗦得多,你还能咋地,批判不够半斤八两?(别忘了 C 之前基本都用汇编写操作系统。)


@Macolor21
> Java 不断被喷的原因就是,每一行代码都必须清晰的表达用什么类型,做了什么事情,看起来像个啰嗦老太婆,但实际上每一行代码都特别清晰。

每一行代码都必须清晰的表达用什么类型 ×
清晰地自以为是 √

比如 Java 10 之前死皮赖脸不肯加 var ,因为一些人自以为没声明显式类型就是“不够清晰”(甚至加了之后还有人想反攻倒算的)。
殊不知有的场景的详细设计就明确要求这里对具体类型进行关注点分离,强调符合设计的类型是满足某特定约束的“任意一种”,而 Java 的类型系统甚至还没能力描述清楚 sum type ;还要求写清楚具体类型那就是妥妥地扯可修改性后腿,反过来毒害设计。
这里被喷的主力就是类似这样的脑补他人合理实际需求不存在,又不懂替代解决方法的自以为是的用户。在某些领域,这些用户被称为民科。
(当 Benjamin C. Pierce 都在反思 more typed 是不是 more expressive 的时候,又哪来这些民科误导舆论的空间呢?)

> 可能一部分人为了显得自己与众不同,高人一等,所以它们倾向于学习成本更高,看起来更简练的语言。

不巧的是,Java 用户中,这类人相对别的语言的用户特别多。于是对剩下的不少用户来讲,与其一个个纠正,还不如先润为敬,反正就是 JVM 生态也有不少别的替代。这样,黑起来就更容易了,不怕误伤友军。
从一开始就不依赖 Java 的旁观者来看,你们这点破事还是省省的好。非得站队,那自然是优先消灭妄图按闹分配的老古董的,免得还有来不及补课基础不牢靠的死硬分子找到借口反智,故意拎不清楚到底是谁在与众不同。——麻烦记住,没人逼你编程来搅乱市场。
提 Rust 的,我就有点好奇,满口 unwrap 口味怎么样……

@cmdOptionKana 别尬黑,http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0534r3.pdf 就没落地,没法用可移植的 C++取得合理的实现。
(虽然你提到的几个语言一样都没这本事,反倒这玩意儿在 boost 里现成有还算能用的实现。)
和 OP 的需求相关的后果是,没有在语言中确保提供类似可移植的功能,就不可能把一般意义的异常处理实现为语法糖,原则上必须原生。(虽然 C++异常一坨 ABI 屑问题,虽然大多数语言一样做不到,以及做得到的语言多数同时自带原生异常,等等……不过都是另外的问题了。)
另外跟 OP 不同的是,我没有发现重启特定软件就一定能医好虚化的问题,不过退出 mstsc 重新进入(只要登得进去)一开始一定没这问题(但之后多少时间再出现问题就不好说了)。
我倒是时有遇到的是整个 RDP 里全部明显虚化(然后可能伴随卡顿)。(虽然我是成天开着 RDP 日用,出问题的频率也不算很离谱。)典型症状是进行重度的 GUI 渲染(比如 BlueStacks……嗯,我就是要顶着延迟用 RDP ,首先是因为硬盘空间比较紧张)一段时间后突然就整个糊了,有小概率在数分钟至数小时不等后恢复。
我的远程机器 ROG G14 ,一直 Win10 ;本地机器 Surface Book 2 ,分辨率更高(还有触摸屏,这也是为什么远程的一个原因)。都是单一显示器 200%缩放(所以 G14 的屏幕就更感人了,这是我宁可远程的另一个原因),因为分辨率不同,登录时更改自适应布局( RDP 会话内 Windows 也是不给改主机的缩放的)。
怀疑是远程主机的 termserv 内部的缓存之类的爆了,然后给了 fallback 。不过没条件调试 mstsc 和 termserv……(或者说,懒。)
发生频率跟远程机的系统版本应该有关。曾经有一阵子虚得很频繁,但是升级到 21H2 (具体版本记不太清楚了)就好很多,不过现在还是没完全杜绝。
另外今天还出现过连续登录缩放后退出:“由于一个协议错误(代码: 0x112f),远程会话将被中断。 请重新跟远程计算机连接。”加上 WSL 还有 mmap 挂掉的,搞不好 NT 内核堆都烂了。想着开了个把月了,还是例行维护一下吧,顺便装更新。结果重启以后这个问题还是解决了。半天下来到现在也暂时没虚化。
@kujio 所以为什么非得要忍 16' 2.5k 屏呢?要 13'这分辨率还好,到 16'了 PPI 上不去,没适配高分屏的缩放不上不下毛边重灾区没得跑。同样 16:10 ,MBP 就强在 PPI 高(你这分辨率就是给 13'用的),然鹅不也长期默认 2x 缩放?
Chrome 几个位置默认都是在 C:,想格系统盘后能用还得多移出来,明显比单独放 AppData 里还更麻烦了(而且改 C:\Program Files 得管理员权限)。位置其实还算正常,重点是不给配置。
@FrankHB 淦,不知道我这里回复框怎么抽风,贴过来几个地方语序乱了……
……算了,不一个个纠正了,反正汉顺字序不影响阅读(
@zooo 我太不同意这里提到的几个说法。
1.正因为记忆力如此重要,才不应该浪费在机械背诵上。
最应该花费记忆的是存那些帮助你找到第一手资料的索引,包括自己阅读技术文档后形成印象——而恰恰不是原文。这样才有可能接近及时获取所需的持久信息的效率的最大化。(当然,看多了自动记住了的东西也不需要刻意忘掉。)
不能上网被逼得记住东西,和你看多了自然记住的东西,即便表面看起来相同,实际上用起来的熟练程度也完全是两码事。
所以看起来最笨的方法,虽然实际不一定是最笨的,但的确是比较笨的;这种看似主动实际被动记忆技能,属于 features of the last sorts 。
如果自己没有形成索引的能力(这其实就是看一手资料提取感兴趣信息的能力的主要部分),那么看二手来源也是可以的,但应该筛选。最有价值记住的是那些容易关联到比较查验权威性的一手来源的资料上,包括综述论文;另外的例子是英文维基百科条目名(虽然不是每个条目都配得上浪费记忆;反正不少条目可以内链间接索引到)。
2.“大量的练习”没有错,但是这里没明说的是,怎么度量“大量”。
实际上,大量不是单独看你处理了多少字面上的材料,而是有使用经验的加权。
比如上面提的,为什么自然记住的东西比强行去记住有效?因为前者通常就是大量使用的结果,跟只是记住完全不是一个概念。
3.专业技术证书是服务于特定的行业和特定的人的,其中的含金量很大来源于“承认”。
这不是你最终能从学习里获得足够回报的保证,例如你不去某些职位工作这些证书可能就一文不名。
如果没有被特定涉众承认的刚需,偏离自身需要去考证可能得不偿失——学了很多实际没用的内容,和被迫通读技术文献中无用的细节浪费的资源效果是类似的,甚至还不如后者能高(装)大( 13 )上一点。
如有可能,尽量看第一手来源。
一般来讲,不要指望别人消化过给你反刍(……D 区.jpg )出来的东西的内容质量,包括纸质出版物,因为本质上对作者的能力和责任心没有门槛限制(说不定理解能力比你还烂),于是跟你花时间踩坑跟随便看什么网文没根本差别。(这种类型的文献里最靠谱的一类也许是综述论文,对作者要求比较严格,写太烂可能圈内社死。)
就算恰好你看到的二次来源没有误导也没有明显的废话,你仍然几乎没可能确保甚至确认里面有没有相对遗漏重要的东西(这个“能力边界”的问题你自己也发现了)——如果一旦需要更权威的来源,那这里看的基本就是沉没成本——因为横竖都得重新过一遍,才能确定。如果你没有事先从一手来源熟练提炼内容的本事,这里阅读的复杂度就是 O(n)往上。
这特别针对“学习笔记”。你不是作者的导师,你没义务花精力替作者审查内容。——别信多看别人的文章就能加深理解的鬼话:这类文献中自己的独创的启发性理解通常极其稀薄,除非你是要学习写作文,否则基本不如直接看书。
博客类的内容,你只适合看发表明确带有具体观点的评论、关于某个时事(可能是当事人观点或者小道消息)的独家报道或者解决极其具体问题的实例,这些内容就是一手来源,不需要寻找更权威的替代。
有权威背书的教程可以看,但是这算是降低门槛(降低读者理解的门槛和作者推广的门槛)用的。如果你恰巧已经对理解一手来源没有障碍,看这种内容还是免不了浪费时间。此时,通常只有在你需要向其他人言传身教时,才有必要参考这些内容。
内容太多不是问题,因为看技术文献本来就不应该通读。如果你觉得自己不能很快通过阅读 preface/foreward/introduction 和有限的正文快速找到感兴趣的内容,说明你现阶段可能不够具备这个能力。这时候,看权威推荐的教程可能更适合你。但这基本可以肯定花(相对)更长的时间——这是无解的,毕竟内容的数量摆在那;况且教程类的东西经常强调非引用性照应说不定还穿插习题,额外开销就更难压缩到 O(n)以下了。
开发嵌入到自己日常生活的工作流的工具,变成刚需,这样不坚持也得坚持,否则没人会替你收拾烂摊子。
坏处是当你真的收拾不了烂摊子的时候就寄了,以及可能不方便公开。
1  2  3  4  5  6  7  8  9  10 ... 77  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2936 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 13:16 · PVG 21:16 · LAX 06:16 · JFK 09:16
Developed with CodeLauncher
♥ Do have faith in what you're doing.