m45t3r

Planck/Lumo for actual projects are really slow and I don't know why (0.5s of startup time). For some reason, the REPL is fast, and I didn't investigate why REPL is fast and an actual project is slow.

It is still relatively simple because the conversion between Pathlib<->str is literally one method call (from pathlib, just call `str(pathlib_object)`, from string, just call `pathlib.Path(str_object)`.

I know this because I started a project using only strings and `os.path`, however when testing it started to become complicate to mock the correct paths so in tests I use `pathlib` (with conversions back to string when I finish path manipulation) and the code still works.

> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS.

There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.

I concur. We use Clojure, and the actual application logic is boring and simple. This is good because it is easy to navigate in code from any project (even from other teams).

Complexity is all at our common libraries. So most programmers don't even need to understand our abstractions, they just work. Of course, sometimes our abstractions are not enough so you need to get your hands dirty. However I would say it works well 99% of the time.

I don't think it is that problematic to put your WiFi credentials to a random website, since the possibility of the creator is a scammer AND lives near enough to you so it can exploits that fact is really small.

However sure, having the piece of mind that this will not happen may still make it more worth it do it yourself.

BTW, if there is anyway that I can get Clojure startup time below 0.1s (actually, until 0.2s wouldn't be so bad, but this is my limit) that doesn't involve something like a daemon running I would be all ears. I would really like "real" Clojure in this case (i.e.: not ClojureScript), since the ecosystem from Clojure is much better.

> Then you must not be up to date then, because at least iOS 12 and iOS 13 both re-asked after updating.

I am up-to-date to iOS 13, however since iOS 13 was basically my worst recent experience with an OS update (tons of things broken and took a while to fix it) you will have to excuse me that I don't remember they asking my privacy settings.

> But there are legitimate business needs for something like this to exist

I didn't say it shouldn't, because I understand. However if Apple is really privacy, they should put this option in wizard with default off, and say something like "if you want personalized ads turn this on". The fact that they turns this on by default and don't show in wizard is my point.

I concur. I am writing a new project in Python after some months writing exclusively Clojure. I decided to write the code using small, pure functions and avoiding classes unless strictly necessary makes the codebase much easier to maintain in the long run.

However I don't think the Python ecosystem is immature, for me it is the contrary. This project started with Python since I didn't find a good way to reduce the Clojure startup time, and believe me I tried everything I found (from GraalVM to ClojureScript). And there is gaps everywhere in Clojure ecosystem when you want to create command line tools, while Python has literally everything I needed.

1) Saying "I want to enable analytics" and marking all options to send analytics by default (since they know most users don't read anyway) is what I am saying that Apple "defaults on". This is still better than other OSes, however if you really are a "privacy first company" is not enough.

However sure, I didn't explain correctly and I don't remember the last time I setup my iPad (this is the only Apple device I have so this will what I will be using for comparison).

2) It still shouldn't exist, or at least they should ask in Wizard because this option I am sure they did not ask because I had to search on how to disable it (and the way to disable it isn't obvious either).

> Self-Correction is important, but even fewer people will do it. Defaults Matter. People just don't dive into VSCode and rip out Microsoft's analytics tracking code en mass. It doesn't happen. People use the defaults.

I concur, defaults matter. I am not saying that Ubuntu is a distro for privacy conscious people, however by default macOS and Ubuntu should have similar levels of tracking (however I do believe that Apple OS phone home much more than Ubuntu, AFAIK the actual tracking/telemetry of Ubuntu is minimal while macOS has the standard for a proprietary OS [1]). That is, much better than Android or Windows, however worse than a distro like Debian, for example.

> In the face of these two assertions; Open Source is important in the fight for Privacy, there's no doubt about that. But even more important than that is Trust.

Sorry, there is no way to trust closed source software. I really think it is strange people claiming that Apple are respecting their privacy and when Apple does things that are controversial to privacy (like the time they're got tracking GPS in iOS devices) they just say "hey, Apple does respect my privacy so it is fine".

For another example, Apple must receive everything you type in Spotlight so they can show search suggestions, exactly the same as the Ubuntu case, however in Apple case it is fine for some reason. Go figure.

I think you're right that you shouldn't trust Canonical, however you shouldn't trust Apple either just because they say in public that they love privacy and because of some of the things they divulge to public, because in the end this is all propaganda: while it is really nice that they have things like encryption by default (BTW, encryption does not increase privacy because if Apple wants they could still read every file in your system), you can't trust Apple that they don't do other nefarious things.

Just to conclude, I think Apple is more trustful than say, Google or Microsoft. However I wouldn't put macOS as a more privacy OS than even Ubuntu (since like I said, the amount of telemetry in Ubuntu should be minimal compared to macOS, and we can never know because it is closed source), and Debian and other Linux distros is really above anything macOS can offer in terms of privacy [2].

[1]: I don't know macOS, however I have an iPadOS and by default it enables by all kinds of analytics, and also generates a unique track ID for ads (you can disable both, however this is the default and at least the option to disable track ID for ads is not shown in the Welcome Wizard, maybe the analytics is shown however I don't remember).

BTW, just looking at the information that Apple makes available in iPadOS about "Analytics Data" it has WAY more information than anything that was said in Ubuntu in this thread (if you want to check just go to Settings->Privacy->Analytics Data). I think macOS should have something similar, but maybe someone else can confirm to me.

[2]: Privacy, not security or other things. Security is something questionable, however I do think most recents version of macOS seems more secure than your traditional Linux distro.

> At least with macOS its all "encrypted" and has sane defaults with a consistent user interface and when some settings are turned off, they stay completely off.

Wait, what. You can completely disable any "phone-home" features of Ubuntu. Actually, you can make sure that this feature is disabled by removing the corresponding package of your system, something that isn't possible in macOS. And you can also audit the code, because all this code is actually open-source [1].

Also, this controversial feature of Amazon search could be disabled quite easily [2], and this motd can also be disabled [3].

So sorry, Ubuntu may have some controversial features, however saying that using macOS is more privacy-respecting than Ubuntu is a lie. They are at least at the same level, however considering that I can't get the source code of macOS and make sure that turning off a knob will stop spying on me, I still think Ubuntu is better than macOS in this point.

[1]: https://launchpad.net/unity-lens-shopping

[2]: https://www.howtogeek.com/126995/how-to-disable-the-amazon-s...

[3]: https://raymii.org/s/tutorials/Disable_dynamic_motd_and_motd...

Better link about the accessibility features: https://www.libretro.com/index.php/retroarch-1-8-2-coming-so...

I am waiting for the 10nm#.

> With that tool, they find that most filesystems drop a lot of error codes:

I recently switched my work notebook to XFS, so looking at this table makes me kinda happy, even if I had bad experiences with XFS in the past (a forced turnoff thanks to a crash in X11 was sufficient to put my system in a unbootable state, trying to recover it with xfs_repair broke it completely; also I suffered with 0-size files randomly appearing after forced reboots quite constantly).

I know for a long time that XFS is probably one of the most well written filesystems for Linux, even if the user case seems to be more focused in servers with uninterrupted power supply than desktops and notebooks.

Well, Instagram [1] and Dropbox [2] are probably the biggest Python projects in the whole world, and they both are using mypy and seem to be successful.

And my particular experience with it is very positive, even if my project that is using it is still small (it is getting bigger though, and mypy is really helping me to refactor it when I needed).

Most of the "false positives" that mypy reports to me end up being code that is overly cleverly, and rewriting it to make mypy happy also improves the code quality.

[1]: https://developers.facebook.com/videos/f8-2018/type-checked-...

[2]: https://blogs.dropbox.com/tech/2019/09/our-journey-to-type-c...

Python can easily get a B for large projects if you use something like mypy. However sure, where the language really shines is as a substitute for scripts, so smallish pieces of code.

And environment... It is complicated. It is not that it is that bad, however it sure lacks some polish. The solution is not easy either since even if you solved the problem today (like using poetry), there is still the whole backwards compatibility problem.

There is various hacks to make things easier, however in the end the problem is still more complicated than it should.

I don't know why people assumed that I never heard or used Sway (or that I didn't read the article). I did all three, and this is why I am saying that the transition from i3wm to Sway is kind painful (ok, my fault for not citing Sway in my phrase, however I did think it was implicit that I used it).

I have tons of scripts that does specific things and are heavily coupled on how X11 works. I need to port them to Sway first.

Most DEs are either already ported to Wayland (Cinnamon, Enlightment), have a porting in progress or plan to port it eventually.

For WMs, it is more uncommon since they're so coupled with X11 specifics that this makes porting harder. However I don't really think it is a problem, if you want to continue using your WM it is fine, it is not that X11 is going away either way.

This is kind the objective I think. Wayland in most cases (Gnome and KDE) is simply an implementation detail, and Gnome and KDE runs in both X11 and Wayland.

The end result is, hopefully, less bugs, more security and more performance, however most people wouldn't care anyway (and I think most people doesn't care, for example Fedora uses Wayland by default).

For us using window managers like i3wm the history is different. However in i3wm I am very close to the X11 so there is almost no abstraction, this is why the transition is more painful.

The point is that a keyboard shouldn't have those kind of problems. If it fixes by itself or if it needs sometime, doesn't really matter because most other keyboards works fines for years.

Well, most packages does not pin dependencies. From the top of my head, proprietary packages generally pin dependencies, however in this case it is because proprietary packages are known to broke when a random library updates.

When I was referring to pinning, it is mostly done locally. I do sometimes, for example, pinning a specific package to a specific commit of Nixpkgs, so I can either backport a new version or avoid some change that I don't want to deal at the moment.

> A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now.

This is untrue. Everytime that a package is updated, thanks to NixOS declarative build system, all packages that depend on it are also rebuild/updated. Unless you're pinning your derivations, it works even on custom packages created by you.

The problem is the tone of voice. One thing is you asking, humbling, why did this happen, if it can be reverted since I had a problem in my specific setup and how I (as the non paying customer) can disable it. The other is to be arrogant saying that I am a multi zillion company, you're idiotic for enabling this feature and I demand you to disable it ASAP and never do this again.

The quote from this article is clearly from the later case, even if I am sure that other people reported it more humbly.

Paying customers should have an option to disable it, however unpaid customers should either rollout their own solution or deal with the consequences of running business with free, uncontrolled software.

Yeah, the fact that Google rolled up a fix in less than two days really shows how good they software engineering is.

I am sure that those multi million dollar enterprises affected by this issue have other softwares so reliable that this was the only time they lost millions on software issue /s.

One thing is "well, your experiment broke our <detailed information of setup>, is there some instructions on how to disable it?" So, well, showing humbleness since this is a software that you're using for free.

The other thing is the way that was described by the article: "I am a sysadmin from a multi zillion enterprise, your idiotic experiment broke our setup. Disable this ASAP and never do something similar ever again".

Any non-trivial piece of code will probably be a pain in the ass to port for a more recent version of the language, and the level of PITA depends on the size of the project X size of the changes in the language.

Case in point, I worked in a project using Ruby. When we migrated from Ruby 2.4.0 to 2.4.6 (yeah, a minor upgrade), it broke spectacularly. Trying multiple Ruby versions, the change was actually introduced in Ruby 2.4.1. After some investigation, a change in Net::HTTP library from stdlib had a change that broke a dependency from a dependency. The fix was just a line of code (we just need to change the adapter used for HTTP communication), however it was two days of work for a minor upgrade.

My current job tried to migrate from Java 8 to Java 11. It also broke multiple services. This one is still in progress, months later.

Python 2 to Python 3 is bigger than both of those version changes (however it is equivalent to Ruby 1.8 to 1.9 changes), so yeah, it does take more time. And like some projects that are forever running Ruby 1.8 or Java 8 (or even worse, Java 6), we will have projects forever running Python 2 too.

Python is probably faster than Elisp (or at least at the same order of performance), and Emacs is fine performance wise. And when Emacs is slow, generally the problem in those cases are architectural/algorithm decisions of Emacs, not because of Elisp itself. And like Elisp, if Python is really slow for some specific part of the code (for example, a function that is used everywhere in the code and it is expensive to run), you can write it in native code (i.e.: C) and call it from Python.

So I can totally see a text editor written in Python being fast enough, probably faster than an editor written in Electron since the runtime is much smaller (Node is faster than Python, however Electron runtime includes a whole browser with it).

I mean, there is some things that Bash really shines, specially for gluing code or working with pipelines.

However, not rarely this ends in a trap: "oh, I already have this small shell script here, I will just add another feature". After sometime, you get a gigantic shell script full of lines that nobody understand anymore, since Bash lacks so many things as a programming language that you end up with multiple hacks just to support that feature you wanted.

I went with the trap above more than once, and sometimes I get myself in it again, until I decide that enough is enough and just rewrite the script in something else.

This seems very interesting, however also dangerous.

I mean, this seems to make Bash a modern programming language, however if you do need something like this a modern scripting language like Python would be better in those cases.