gue5t

Files have awful semantics in just about every way. We should get rid of them ASAP.

Depends on your application. Run the programs you want to run on this and open powertop. It can also be informative to run them under strace and see whether their mainloops spin or wait; any well-written program sleeps until it has real work to do.

Not one of those had free drivers on any consumer-available hardware, so you're limited to kernels compatible with your binary blobs, which then limits your userspace, which leaves you firmly stuck in the insecure, slowly bitrotting past. All of them except Tizen were using Android kernels and bionic libc, and Tizen is a fucking garbage fire (read some of their GPL dumps or try to navigate their bizarre code-dumps-in-branches repo structure sometime).

Desktop Linux is a success (as in, a viable option for those who want to avoid the downsides of proprietary OSes); the only reason there isn't such a viable non-user-hostile OS option on phones is driver support, and this effort says they'll ensure free-software drivers.

Plus, by avoiding the braindead "App Store" model, you instantly have access to a huge and growing base of software, all for free. Finding software for Android is a hellish experience marred by invasive ads, malware, loads upon loads of spam, crappy wrappers for actual free software, profit-grubbing clones on the app you actually wanted, etc. By removing the perverse incentive of "users = $$$" the user experience of finding software improves drastically.

The GUI of most free software isn't well-suited to a phone, but I would far rather wait for UI revamps while using software that does everything I want, as opposed to having to just shrug and give up on finding a web browser with a web inspector--what I ended up doing under Android and iOS.

It certainly isn't; it's killed by SIGPIPE after printing 50 lines. If I wanted to wait for the entire system log to read off of disk I'd be sitting for minutes.

"journalctl -r -n 50" takes 5.4 seconds as of a test just now from (this time, artificially) cold cache.

I don't have enough RAM that journal is usually in cache (just anecdotally, it seems to always be slow the first time in a session that I run it). Nonetheless, I can access most uncached contents of my disk much faster than this:

    $ time journalctl -r | head -n 50
    (...)
    journalctl -r  0,01s user 0,04s system 0% cpu 5,289 total
    head -n 50  0,00s user 0,00s system 0% cpu 5,287 total

If your lifestyle involves embracing the capitalist consumption treadmill of buying new hardware every couple of years, systemd-journald may be for you. Otherwise prepare to be told to throw away perfectly good computer hardware because Lennart is too lazy to design software that can cope gracefully with disk latency.

1/2/3: No, it isn't that bad, but disable resolved and networkd, and coredumps, and prepare to hate journald with all your being because of how insanely mindbogglingly slow it is (owning a hard drive rather than an SSD is an unsupported configuration for journald). The init daemon is much better than init scripts; it isn't elegant, but it is at least declarative and efficient.

It seems likely that the gp is talking about what.cd successor redacted.ch, not the "YouTube Red" paid streaming service.

Is this using the same techniques as the old mostly-vaporware "cantor dust" project? It looks very similar.

https://www.reddit.com/r/ReverseEngineering/comments/2apw6l/...

This is basically just FUD.

Unless I'm mistaken, Google isn't interested in upstreaming these changes. A quick search of lmkl.org doesn't show any hits for the switchto_... APIs.

I'd love to hear otherwise or in more detail from someone at Google. It's frustrating to have to do archaeology just to guess what the state of the art is. Isn't sharing your findings part of "organizing the world's information"?

See this presentation about Google's scheduler patches, which claims the major overhead is logic in the scheduler (pg16): http://www.linuxplumbersconf.org/2013/ocw/system/presentatio...

+1 on single-copy frequently being faster than zero-copy. See https://lwn.net/Articles/580194/ for a real-world example from the Linux kernel.

On the topic at large, I think microkernel vs monolithic is not actually the important distinction in kernel design; robustness could improved vastly if the business logic of a kernel were implemented in a memory-safe language instead of C or C++. Register bashing and system setup won't ever be effectively captured by a typesystem (knowing what the semantics of hardware are is the hard problem, and GIGO applies to typesystems as much as anything), but most vulnerabilities are in code that doesn't directly interact with hardware (even if they're in a driver for some obscure hardware, it's generally the syscall-facing side that gets exploited).

I'd like to see more OS development look at non-UNIX designs, rather than trying a million different ways to implementa UNIX-like interface.

Imagine the "value" investors could make if they cordoned off every useful composition of Linux kernel features into a "product" like this.

No, Ubuntu's phone efforts refused to take a stance of promising open-source drivers (because they didn't care about solving this problem for their users, they just wanted to be a phone OEM). Whether the kernel has the Android patches or not isn't the important factor; it's whether the device drivers (kernel and userspace) can be maintained by the community.

Thanks for being the only person in this thread that understands the real root problem. Proprietary drivers are the only reason phones don't get software updates forever from the open-source community the way the P4 you've forgotten in a closet someplace does.

(Employee performance, not software performance.)

There are a number of statements like "QUIC is functionally equivalent to TCP+TLS+HTTP/2" in the "QUIC wire specification" and other documents, and this agrees with what I remember seeing in the source in the Chromium repo when I last looked.

I've not read about the IETF version; I'll look into it.

This seems really complicated. Is ZeroTier closer to an cjdns- / i2p-style system, or is it closer to CurveCP/MinimaLT/QUIC? (QUIC being the odd one out of the trio as it grafts on some awful HTTP semantics, but that's Google for you.)

> What about the "binary blobs" do you not understand.

I don't understand the assumption that minified and obfuscated javascript is easier to reverse-engineer than compiled wasm is. This is simply untrue. In both cases the user is, in general, running a closed source (in the GNU sense of "the preferred format for code modification") system that doesn't have their best interests in mind.

Adblockers are much the same war as antivirus was: you want to run untrusted code but still have some say over which computation it performs. Unlike with antivirus, sandboxing and isolation don't help. We're just going to be writing heuristics to strip ads forever (or until we standardize on a non-executable document format, e.g. html-without-scripts).

You're entirely right, but "it is difficult to get a man to understand something, when his salary depends on his not understanding it" certainly applies to the entire "tech" industry, and the app factory in particular.

I expect this realization will only become widespread when open-source folks actually fix their software's deep-seated usability problems. The way to do that is not by hiring UX designers or appifying it; it's by thinking deeply about how humans interact with computers and blowing away the conventions that make computers and software unforgiving, hard to explore, and opaque to the uninitiated.

All understanding of X11 feels this way. Read the docs and source yourself sometime.

Except for the important metrics of inequality of QoL/income/wealth.

It'd be cool if someone would replicate this on Linux under X11 and a few Wayland compositors, and throw urxvt, rxvt, xterm, aterm, and some others in the mix.

This is going to sound mean however I say it, so I'm not going to sugar-coat it: that's how pretty much all suckless software works. Software becomes fast via profiling and optimization, not by ritualistically applying dubious notions of simplicity (C is simple? since when? UNIX is simple? since when?).

The site hijacks scroll which is pretty upsetting.

Every medium decays; if you don't estimate longevity and perform error correction/migration/etc. accordingly, you won't be immune to data loss, just blindsided by it.

I've read a lot of Tizen code, and EFL is by far one of the more professional and well-engineered components. And this is realizing that in relation to many open-source libs EFL is rather a goofy oddball.

95% of Tizen is a huge hairball of needless nested and overlapping indirections (custom IPC layers, serialization formats, "management" daemons, libraries to interface with them, etc.) implemented in varying (except for the pervasive messiness and broken english) C styles; deep beneath all this you have the open-source libraries doing the actual useful work. You could try to make some similar claims about Android, but the percentage would be much lower and the code quality is much higher. I wish I had some real metric to point at (maybe this article suffices?) but the code in Tizen is truly awful.

Also they don't give a shit about their bug tracker; I've had system-breaking bugs, with patches, in "new" status for over a year. Because I don't work at Samsung, I can't contribute.

Meson is strongly-typed; it goes beyond just having a notion of "paths" and tracks what kind of object paths point to, and what kind of resource strings name. This is invaluable, because it means you get feedback when you accidentally pass an object file instead of a library name or any number of other confusions.

Personally, this meant the error messages I got were helpful enough that my first meson-built project was working after a half-hour of deciding to port it over despite using several system libraries and doing compile-time code generation.

Meson's language is not Turing-complete, so it's easy to analyze for errors. Unlike CMake and autotools, Meson's language looks like a real (pythonish) programming language, and it isn't string-oriented; dances of escaping, substitution, and unescaping are uncommon.

Compared to autotools or hand-rolled Makefiles, CMake is a step in the right direction; meson is a leap.

Xorg used to get SIGIO on input; it's now less responsive and uses threads: http://who-t.blogspot.com/2016/09/input-threads-in-x-server....

Check out meson; it seems to be the future for projects that were using CMake or autotools. It's certainly a joy to work with in comparison.