1. 5

    People often call me silly for sticking with my old 4:3 17” monitor. But then when I see the hoops people jump through (and yes I know, this link is being deliberately silly, but there’s a grain of truth in it) to try to make their huge extra-wide monitors actually usable for daily tasks, I’m thinking they’re the silly ones.

    1. 1

      Which one do you use?

      5 years ago when I moved from Boston to the Bay Area I left behind my 3x2 array of Dell 2007fp monitors (20.1”, 4:3, 1600x1200) because they were way too power consuming, falling apart, and heat generating, but I miss them every day.

      I would go back to that setup in a heartbeat but you just can’t buy anything with even roughly the same specs but modernized.

      1. 2

        I have three, all about the same. One is an acer v173 (that’s my first… my mother bought it for me for my birthday in like 2007. it recently refused to turn on so I had to swap it out but more on that later. I think it is a capacitor failure but I can’t figure out how to get the cover off to test/replace it! it feels like the plastic is fused together). One is a HP 1755 that I actually like kinda a lot too, it has both VGA and DVI inputs and can switch between them, so I use it as a secondary monitor.

        Then the third, which is replacing my Acer right now, is a Dell… E 173 FP. Interesting, both it and the Acer have 173 in the model. I wonder if that’s just coincidence or if it has more meaning. The Dell I got off a used trash heap and it does have some bright and dark spots in its screen but it is very minor and I still find it quite usable. (I’d love to fix my Acer some day though! Its screen is still working excellently and it is a bit darker than the Dell’s.)

        Anyway, they’re all 17” across and run at 1280x1024 which I find works very, very well for a desktop computer. It is detailed enough to have the space but not so big that I’m turning my head or breaking my wrist trying to fling the mouse across the screen. I do have that HP hooked up too, so if I want to watch a video or remote desktop to a work computer, I can do that over there while keeping the main screen ready for my own work. (And I have a custom xrandr setup to ease this - instead of putting them side by side, I put the two screens touching by corners on the virtual framebuffer. So the one screen is upper left and the other is lower right. This means the edges of the screens remain barriers keeping the mouse cursor corralled so it doesn’t get lost on the wrong monitor (I leave the second one turned off if not actively using it), yet it is also easy to deliberately move the mouse between the two by just aiming for the corner. Fitts’ law in action! Then my custom window manager always redirects full-screen windows to occupy only the second monitor, so the video player, etc. naturally lands over there keeping my main screen ready for using. I’m very happy with this setup and I’ve never seen anyone else do a thing similar.

        Anyway, my monitors all pull about 20 W when operating… the internet tells me your things eat 75 W… yikes. I can see how that’d add up fast and get hot. I can’t complain too much about my 20 W, though I am sometimes tempted to buy a new one to see if they are any more energy efficient…. just all the new ones come in these sizes and shapes I simply don’t care for. So I’ll keep recycling and repairing other people’s trash as long as I can.

      2. 1

        You just don’t fill the screen with one thing. Like a physical desktop, you put multiple things on it so you can look at them at the same time.

        The only thing wrong with those ultra-wide monitors is the resolution — the ones I’ve seen are all still stuck at around 100ppi. I refuse to stare at blurry text or graphics anymore.

      1. 1

        Yes, and throw in wanting different DPI scalings on the different screens as well (impossible by design under X, not sure about Wayland).

        1. 3

          impossible by design under X

          What design is that?

          X, in fact, supports (at least) three different ways to do it: 1) run separate “screens”. This is the original way, but it doesn’t let windows move from one to the other; they must be destroyed and recreated on the other one, meaning it would jump across the transition instead of being simply dragged over and would require cooperation from the application. A bit of a pain. 2) Have xrandr connect the screens plus use a compositor to upscale everything on the lower dpi monitor to the higher one or vice versa. (This btw is also what Wayland chose to do.) Relatively easy to set up and can be done without the application’s cooperation. Or 3) Have xrandr connect the screens and then present the size difference to the application and let it scale itself. This requires cooperation from the application again.

          It might not be easy, but it certainly isn’t impossible. I remember when getting X running at all was a bit of a pain. Then they did some work and actually did made it easy.

          1. 2

            This very recently bit me and I ended up going back to Windows (among other reasons). I have a 1440p monitor and a 4K vertical monitor and trying to get mixed incremental scaling was a bit of a nightmare. And when I did manage to get it working under (GNOME) Wayland, it was horribly laggy on the 4K display (getting it going on X11 was basically a no go with the amount of effort required).

          1. 2

            I started writing a browser on Thursday and I wanna see how far I can get on it. No, not an actually from scratch browser; a skin on chromium. I know, I hate it too, but it is the most practical option I have to get something that can potentially replace horrible Firefox and Edge with their bad UIs that manage to get worse every other release as a daily driver I actually use.

            I already have a better file dialog Firefox on linux :P

            1. 1

              Not sure what the point of this is when Wayland has been on EGL already. Why not just deprecate and later remove X11 support? It’s not like the Firefox team has infinite resources.

              1. 3

                There’s a large number of people who will need to get FF updates but won’t be / can’t be on Wayland. I expect another decade of X11 having a significant market share. The Wayland protocols take ages to stabilise… Even the trivial ones like screensaver inhibitor take 6 years and counting.

                1. 1

                  Wayland can’t do anything X can’t do and X can do plenty Wayland can’t. Really, the intelligent, rational decision would be to remove Wayland support…

                  1. 1

                    Aside from security, I know 3 things only Wayland can do, which I know on top of my head because they are that irritating in X:

                    • Alt+Tab out of any fullscreen program (unless implemented/emulated in said program, if I understand correctly)
                    • Displaying video without tearing
                    • Work after a kernel upgrade without rebooting (just my experience: Weston works whenever X doesn’t)

                    That said, I would agree that Wayland is the least usable right now. Firefox in Xwayland can’t reorder tabs, and in Firefox in Wayland mode (MOZ_ENABLE_WAYLAND=1), copypaste is broken and hover text flows outside the screen.

                1. 4

                  I appreciate the author going through the drudgery of actually taste-testing all of these different libraries, though their requirements are not my requirements.

                  One of the big things they point out is “hey, I just want to use the language package manager…why you gotta make this weird?”. That’s an issue that exists in all ecosystems, and one that I think doesn’t get enough attention. Windows is often treated as an afterthought/third-class citizen by developers (which is hilarious, since Windows solved the GUI stuff “well-enough” two decades ago that devs these days mostly punt on and use Electron for, but that’s a whole different thing…) who aren’t perhaps used to dealing with an OS where developer ergonomics is not in the Unix mold. Even with WSL2, it can be a bear treading the path outside of Microsoft’s blessed tooling–this is a truth that needs to be accepted.

                  Another thing the article points out around accessibility is the number of libraries that just…don’t. I wish the author went into more detail about this, but basically any library that uses OpenGL/Vulkan/DirectX/whatever directly (and handles its own book-keeping internally for widgets and stuff) is going to have a hard time with accessibility and require extra work to get there. If you aren’t using the native OS parts for that, or using a layer that handles it for you, this is bound to be an issue.

                  I am a little annoyed that the author disqualified the most successful of the offerings–the native-windows-gui library–because of a sudden surprise concern about cross-platform development, which makes me a bit suspicious about the integrity of the article as a whole. That said, it’s still a good summary if you have the constraints the author seems to.

                  1. 4

                    I find running Windows applications on wine/linux is easier than running “native” Linux programs. And since wine is not an emulator … I’d say Windows api is cross platform :)

                    (only half kidding)

                    1. 2

                      Unironically this. Proton has given Linux gaming a useful set of APIs to develop against.

                      1. 1

                        Proton

                        huh my first time actually hearing about this (shows how much i follow the game world). But yeah it legit makes sense, and it does for desktop apps too. The Windows API is actually pretty good and Wine does a solidly ok job.

                        I do find it a bit weird how the same people who will taut a browser-based thing as “finally on Linux” will disregard wine.

                  1. 9

                    A less publicized and unintended use of the GPL is that it is very favorable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior.

                    That’s quite a claim. Is there evidence to back it up?

                    I’ll admit I focused much of my reading on the GPL Advantages and Disadvantages, and BSD Advantages sections. (Because if it wasn’t clear this article is biased, the BSD section title doesn’t announce Disadvantages). I personally find some of the disadvantages listed for GPL to be advantages, and the potential for abuse by corporations of the BSD to be downplayed.

                    1. 9

                      I expected the article to be biased as it’s on the FreeBSD site. Also, I found it odd that this bit:

                      In contrast, those who expect primarily to use a system rather than program it, or expect others to evolve the code, or who do not expect to make a living from their work associated with the system (such as government employees), find the GPL attractive, because it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially “burying” or orphaning the software.

                      was listed under the BSD Advantages section. This is an advantage of the GPL—allowing users to obtain the source code so they can continue to use and improve it even if it’s orphaned.

                      1. 5

                        Note that the title is why you should use the BSDL for your project, so advantages that are only advantages to consumers of your code who don’t contribute anything don’t count. That said, I don’t really like this article. My main reasons for preferring permissive licenses pretty simple:

                        • I want to be able to get contributions from as many people as possible. In my experience, a copyleft license puts off more contributors than a BSD license. I’ve worked with companies that have paid for someone to rewrite LGPL’d libraries that they were using internally (not even distributing) and then open source them rather than have to properly understand what the LGPL does and doesn’t let them do.
                        • If I get external contributors and I want to reuse their code in another project (personal or for work) I don’t need to think about it.
                        • I know some fantastic IP lawyers and I’m happy to talk to them but getting a straight answer from them about a point of law is almost impossible and I really, really don’t want anything I do to be gated on this. Even the LGPL is quite fun here because it tries to encode the C compilation and linkage model in legalese. If I take an LGPL’d library (e.g. GNUstep Base) and dynamically link it with my application, which provides a category that replaces one of the undocumented internal methods on a core class (such that any user who replaces their version of the shared library will keep using my version), am I violating the LGPL? How does LGPL work with header-only C++ libraries?
                        • More philosophically, I don’t believe that the GPL works well from a psychological perspective. Folks who have been forced to release code by the GPL are never enthusiastic participants in a Free Software ecosystem. The GPL encourages people to come up with exciting work arounds, which then lead to more complicated versions of the license to try to close the loopholes (see: nVidia Linux drivers, for example). I’d rather that people who want to just consume BSDL code do so and go away: they can deal with all of the problems of merge conflicts and upstream implementing incompatible versions of their features and then decide to participate in the ecosystem because they see concrete benefits. This process often takes 10+ years but at the end the companies that have learned this lesson are great to work with.

                        Most copyleft licenses don’t protect against the threat models I care about for Free Software because they’re entrenched in the COTS model. The GPL didn’t prevent Google from having a private fork of Linux with their own filesystem drivers and not sharing the changes. AGPLv3 might, but it’s not entirely clear to me that it actually works in practice (and it definitely does put off a lot of potential contributors). I might put up with some of the other disadvantages if they actually helped me address this (I might not - it actually doesn’t bother me if other people make something better out of my code, it’s just a bit rude if they don’t share it with me).

                        1. 2

                          I’ve worked with companies that have paid for someone to rewrite LGPL’d libraries that they were using internally (not even distributing) and then open source them rather than have to properly understand what the LGPL does and doesn’t let them do.

                          What I’m getting out of this is LGPL code creates paying jobs :)

                          1. 1

                            I’d rather that people who want to just consume BSDL code do so and go away

                            In case you care about community around a software product (not everybody does): That only works if they can’t make their variant the dominant version and make everybody else “go away”, too. A BSDL Linux (without the USL lawsuits in recent memory that plagued everything *BSD) managed by IBM (if they’re smart, hiding behind a trade org like Linux Foundation, and inviting their UNIX buddies) that offers extra features could have blown apart the “upstream” BSDL Linux variant.

                            So what we have now is a similarly managed but still fully open Linux.

                            What the “have to come up with exciting workarounds” strategy offers is that it always keeps troublemakers at least a bit off-balance: Their IP lawyers are just as unwilling to give a definite rule to go by as yours are.

                            1. 6

                              So what we have now is a similarly managed but still fully open Linux.

                              Do we? I suppose that’s mostly true for the kernel, but the dominant flavour of Linux today is Android and it is very difficult to take a particular vendor’s Android and make it work. If you remove all of the non-Free Google bits from Android, you end up with a system that can’t even run all of the things in F-Droid due to their dependencies on Google Play Services and you’ll quite often see drivers with a vaguely open shim that don’t work with new kernels or 100% proprietary drivers on the Android HAL infrastructure.

                              IBM is now the owner of Red Hat and controls systemd and glibc and has exerted a lot of pressure on the rest of the ecosystem to make it hard to run desktop Linux software without building dependencies on IBM-controlled technologies. They’ve done exactly what you suggest: put things in the Linux Foundation, invited a bunch of other companies.

                              Neither Google nor IBM needs a proprietary fork to exert control over their ecosystems, even if they were to start with something BSDL’d they probably wouldn’t do more than they’re doing now.

                              1. 1

                                Neither Google nor IBM needs a proprietary fork to exert control over their ecosystems, even if they were to start with something BSDL’d they probably wouldn’t do more than they’re doing now.

                                I disagree, but then Fuchsia is BSDL (with userland BSDL or Apache-L which is mostly the same, just in many more words), so I guess we’ll see.

                                1. 1

                                  I suppose that’s mostly true for the kernel

                                  That’s barely true for the kernel, too. In 10+ years of working on embedded Linux gadgets of various kinds I have never, not even once, used, or seen, a device using anything near a vanilla upstream kernel. I don’t mean developer boards and the like, I mean real-world products. There are some success stories but replicating them is difficult to the point of being impossible unless you’re on really good terms with enough suppliers and service providers (so basically unless you’re either a company the size of nVidia, or a small company whose CTO/CEO/C-whatever used to work for a company the size of nVidia).

                                  A good hunk of my job, at various times, consisted in either getting various modules/peripherals/devices/whatever that were supposedly supported upstream to work (which required anything from trivial fixes in upstream drivers to significant rewrites), or getting various manufacturer-supplied drivers to work. The story with the latter being that the device “supported Linux” as in the manufacturer would give you a BSP running on some Frankenstein kernel from four years ago and the driver had to be ported to some other Frankenstein kernel from two years ago.

                                  Most of these “local” fixes never make it upstream. Mine certainly didn’t. Mostly for the reasons you’d think they don’t, like bureaucracy or lawyers, both of which are a thing for any open source contributions but are two extremely big things for GPL contributions. Others are kept in house for reasons that have nothing to do with community building, though (e.g. fixes don’t get contributed because upstream is broken enough that being able to get it to work on $hardware brings in a lot of customers by word of mouth).

                                  (Edit: I’ve also seen the opposite effect. $company has a “strategic interest” in a particular program or subsystem and it contributes a lot of code. Most of it is garbage, and it gets in because the maintainers doing the reviews also work for $company and upstream eventually just becomes $company’s working tree).

                                  Desktops and laptops are a somewhat special case, for a variety of reasons (open standards, widespread availability, inertia, Windows drivers to reverse engineer and so on) but generally speaking, it’s very hard to get the upstream Linux kernel and make it work. Even on platforms that are pretty well-supported – there are plenty of SoC vendors that treat Linux as a first-class citizen and upstream support really is good, but as soon as you hook up a peripheral that you can realistically use for volume production to it, you’re screwed.

                                  IMHO the GPL made a lot of sense way back, but like many other things, IP lawyers figured out how to use it for, uh, other purposes, too, not all of them conducive to competitiveness. BSD stood the test of time a little better, if only because it didn’t try to restrict as many things as the GPL did.

                                  1. 1

                                    it’s very hard to get the upstream Linux kernel and make it work

                                    I wonder if that is because embedded Linux is not a priority for Linus. He cares about his desktop and he cares about the servers of those who finance his income (through Linux Foundation).

                                    1. 2

                                      I can’t speak for Linus but embedded Linux is not just a huge area in and of itself, it’s a huge part of the kernel as well. Until a few years ago, that’s what drove kernel support for ARM and PowerPC, a whole lot of work in the USB subsystem, and an uncanny amount of drivers, to name just a few things.

                                      It’s not that embedded Linux isn’t a priority for upstream kernel development, it’s just that upstream kernel development isn’t much of a priority for a lot of hardware vendors. For every vendor like… dunno, Analog Devices, or ARM, there are ten vendors that will just give you a four year-old BSP with kernel 4.2 and if you don’t like it go ahead and port it yourself. You can always go for other vendors, of course, and you’ll often get much better hardware, too, but good luck meeting the budget constraints that consumer devices have today, when they’re supposed to go obsolete in a year or two.

                                      1. 2

                                        It’s been 0 years since I last bought a device that unironically used 2.6.x.

                          2. 4

                            I have to admit that I’m personally a bit bothered by the trend lately of projects switching to copyleft and “shared source” type licenses as an anticompetitive tactic. The people who originally started a project and hold the copyright can use these types of licenses — combined with CLA/assignment — to set up a position where they get to do proprietary-style things like a SaaS business with “secret sauce” bits they don’t release, while forbidding any competitor from doing so. I’ve never understood how that promotes “software freedom”, or is supposed to be good for users who get trapped in an effective proprietary monopoly.

                            1. 3

                              Indeed, whether the FSF intended it to be used as such or not, the largest AGPL users seem to be using it effectively to promote sales of proprietary license exemptions.

                              1. 3

                                It’s always amused me somewhat that the FSF’s revenue used to be almost entirely from the sale of proprietary software: if you violated the license on an FSF project then they would sell you a retroactive license with an explicit sunset clause (at which point you had to be in compliance).

                                The kind of dual-licensing that MySQL and others did always bothered me because it is an explicit statement that the Free Software version is less valuable than the proprietary one: the proprietary one is expensive, the GPL’d one is free. This is the exact opposite of the message that I want to be sending: that the Free Software version is more valuable than the proprietary one.

                              2. 1

                                I’ve never understood how that promotes “software freedom”, or is supposed to be good for users who get trapped in an effective proprietary monopoly.

                                “Shared source” doesn’t claim to be about software freedom.

                                As for copyleft, the original sin might have been the FSF establishing the idea of CLAs in the copyleft context. Yeah, they’re all great and will always be splendid stewards (but will they?) but through this they provided a blueprint for open core models.

                                In any case, the issue arising out of CLAs is easily fixed: Fork software that requires CLAs (or anything like that) at the earliest opportunity, and move the community to where there is no single arbiter of ownership. Shared source models don’t offer the same opportunity.

                              3. 2

                                That’s quite a claim. Is there evidence to back it up?

                                From a BSD perspective, Linux ate their lunch. That IBM (large company) announced to “spend one billion dollars on Linux” (marketing weapon) back in 2000-or-so, affecting (undercut) various smaller BSD outlets (“software companies”), might be part of that lore.

                              1. 23

                                I enjoyed this quite a bit when I first saw it, and I still do kinda enjoy the original - it was never meant to be taken too seriously of course and it succeeds as a joke - but since then, the word “wat” has become a trigger of rage for me.

                                These things tend to have a reasonable explanation if you take the time to understand why it does what it does. They tend to be predictable consequences of actually generally useful rules, just used in a different way than originally intended and coming out a bit silly. You might laugh but you can also be educated.

                                But you know how often I see people taking the time to try to understand the actual why? Not nearly as often as I see people saying “WAT” and just dismissing things and calling the designers all kinds of unkind things. And that attitude is both useless and annoying.

                                1. 38

                                  These things tend to have a reasonable explanation if you take the time to understand why it does what it does. They tend to be predictable consequences of actually generally useful rules, just used in a different way than originally intended and coming out a bit silly.

                                  For me the most important takeaway is that rules might make sense by themselves, but you have to consider them in the bigger picture, as part of a whole. When you design something, you must keep this in mind to avoid bringing about a huge mess in the completed system.

                                  1. 4

                                    Exactly. It is generally underappreciated how incredible hard language design is. The cases Bernhardt points out are genuine design mistakes and not just the unfortunate side effects of otherwise reasonable decisions.

                                    That’s why there are very few languages that don’t suffer from ugly corner cases which don’t fit into the whole or turn out to have absurd oddities. Programming languages are different, contrary to the “well, does it really matter?” mindset.

                                    1. 3

                                      I don’t know. What I always think about JS is that R4RS Scheme existed at the time JS was created and the world would be tremendously better off if they had just used that as the scripting system. Scheme isn’t perfect but it is much more regular and comprehensible than JS.

                                      1. 3

                                        I think one have to remember the context in which JavaScript was created; I’m guessing the main use case was to show some funny “alert” pop-ups here and there.

                                        In that context a lot of the design decisions start to make sense; avoid crashes whenever possible and have a “do what I mean” approach to type coercion.

                                        But yeah, I agree; we would’ve all been better off with a Scheme as the substrate for maybe 80% of today’s end-user applications. OTOH, if someone would’ve told Mozilla how successful JS would become we could very well have ended up with some bloated, Java-like design-by-committee monstrosity instead

                                      2. 2

                                        I don’t think I know a single (nontrivial - thinking about brainfuck/assembly maybe) programming language with no “unexpected behaviour”.

                                        But some just have more or less than others. Haskell, for example, has a lot of these unexpected behaviours but you tend not to fall on these corner cases by mistake. While in javascript and Perl, it is more common to see such a “surprise behaviour” in the wild.

                                        Another lesson I gather from this talk is that you should try to stick as much as possible in your well-known territory if you want to predict the behaviour of your program. In particular, try not to play too much with “auto coercion of types”. If a function expects a string, I tend not to give it a random object even if when I tried it, it perform string coercion which will most of the time be what I would expect.

                                        1. 1

                                          Well, there are several non-trivial languages that try hard not to surprise you. One should also distinguish betweem “unexpected behaviour” and convenience features that turn out to be counterproductive by producing edge-cases. This is a general problem with many dynamically typed languages, especially recent inventions: auto-coercion will remove opportunities for error checking (and run-time checks are what make dynamically typed languages type-safe). By automatic conversion of value types and also by using catch-all values like the pervasive use of maps in (say) Clojure, you effectively end up with untyped data. If a function expects a string, give it a string. The coercion might save some typing in the REPL, but hides bugs in production code.

                                      3. 3

                                        In javascript, overloading the + operator and the optional semicolon rules I would call unforced errors in the language and those propagate through to a few other places. Visual Basic used & for concatenation, and it was very much a contemporary of JS when it was new, but they surely just copied Java’s design (which I still think is a mistake but less so given the type system).

                                        Anyway, the rest of the things shown talk I actually think are pretty useful and not much of a problem when combined. The NaNNaN Batman one is just directly useful - it converts a thing that is not a number to a numeric type, so NaN is a reasonable return, then it converts to string to join them, which is again reasonable.

                                        People like to hate on == vs === but…. == is just more useful. In a dynamic, weakly typed language, things get mixed. You prompt for a number from the user and technically it is a string, but you want to compare it with numbers. So that’s pretty useful. Then if you don’t want that, you could coerce or be more specific and they made === as a shortcut for that. This is pretty reasonable. And the [object Object] thing comes from these generally useful conversions.

                                        1. 3

                                          == vs ===

                                          It definitely makes sense to have multiple comparison operators. Lisp has = (numeric equality), eq (object identity), eql (union of the previous two), equal (structural equality).

                                          The problem is that js comes from a context (c) in which == is the ‘default’ comparison operator. And since === is just ==, but more, it is difficult to be intentional about which comparison you choose to make.

                                          1. 1

                                            Well, a lot of these things boil down to implicit type coercion and strange results due to mismatched intuitive expectations. It’s also been shown time and again (especially in PHP) that implicit type coercions are lurking security problems, mostly because intuition does not match reality (especially regarding == and the bizarre coercion rules). So perhaps the underlying issue of most of the WATs in here simply is that implicit type coercion should be avoided as much as possible in languages because it results in difficult to predict behaviour in code.

                                            1. 1

                                              Yeah, I perfer a stronger, static type system and that’s my first choice in languages. But if it is dynamically typed… I prefer it weaker, with these implicit coercion. It is absurd to me to get a runtime error when you do like var a = prompt("number"); a - whatever; A compile time error, sure. But a runtime one? What a pain, just make it work.

                                              1. 3

                                                Lots of dynamic languages do this (e.g. Python, Ruby, all Lisp dialects that spring to mind), and IME it’s actually helpful in catching bugs early. And like I said, it prevents security issues due to type confusions.

                                        2. 10

                                          Yeah, I think that this talk was well-intentioned enough, but I definitely think that programmers suffer from too much “noping” and too little appreciation for the complexity that goes into real-world designs, and that this talk was a contributor… or maybe just a leading indicator.

                                          1. 6

                                            There was a good talk along these lines a couple of years ago, explaining why javascript behaves the way it does in those scenarios, and then presenting similar ‘WAT’s from other languages and explaining their origins. Taking the attitude of ‘ok this seems bizarre and funny, but let’s not just point and laugh, let’s also figure out why it’s actually fairly sensible in context’.

                                            Sadly I can’t find it now, though I do remember the person who delivered it was associated with ruby (maybe this rings a bell for somebody else).

                                            1. 1

                                              Isn’t the linked talk exactly the talk you’re thinking about? Gary is ‘associated with’ Ruby and does give examples from other languages as well.

                                              1. 2

                                                No. I was thinking of this, linked else-thread.

                                            2. 3

                                              While things might have an explanation, I do strongly prefer systems and languages that stick to the principle of least surprise: if your standard library has a function called ‘max’ that returns the maximum value in an array and a function called ‘min’ that returns the position of the minimum element instead, you are making your language less discoverable and putting a lot of unnecessary cognitive load on the user.

                                              As someone who has been programming for over 20 years and is now a CTO of a small company that uses your average stack of like 5 programming languages on a regular basis I don’t want to learn why anymore, I just want to use the functionality and be productive. My mind is cluttered with useless trivia about inconsistent APIs I learned 20, 15, 10 years ago, the last thing I need is learning more of that.

                                            1. 6

                                              I wonder if this is more or less the end of the road for the librem 5?

                                              This offers similar openness, same software capability and slightly better specs (I think…). And hardware privacy switches too. For half the price, assuming Chinese assembly meets your requirements. (If you need a US-manufactured device, Librem offers that for $2000-ish, and Pine does not.)

                                              And given the respective companies’ track records, it seems likely the ’Pro will ship in quantity well before the listed 52-week lead time on the non-US-manufactured Librem 5.

                                              I was on the fence between replacing my iPhone’s battery or just replacing the whole phone. I think this announcement has pushed me toward replacing the battery and revisiting in 8 - 12 months to see if this has developed into something that could be a daily driver for me.

                                              1. 14

                                                Purism is targeting a different market; they’re trying to make an ecosystem, a readymade device, that someone can use out of the box and be satisfied with. I don’t think they’re doing all too well with it, but it’s the intent that counts. What Pine does is make tinker toys for engineers. They save money on the device by punting software engineering to the users. (The battery management part made me queasy.)

                                                1. 7

                                                  I agree with your characterizations of the two intents. What I meant to do in my comment is question whether, given that the software works as well on the pinephone as it does on the Librem, has Pine backdoored their way into (soon) hitting that “someone can use out of the box and be satisfied with” goal for technical users better than Purism has even though they were aiming for something else entirely.

                                                2. 8

                                                  A big difference for me is that the L5 has privacy switches that are usable. That is, I want the camera and microphone off until I’m receiving a call, then I can flip the switch and answer. With the pinephone (and it looks like the pinephone pro) the switches are buried inside the back which make them interesting but not very usable in day-to-day life.

                                                  Another point as mentioned in other comments is that Purism is funding the software development to make the ecosystem. Pinephone gets the benefit of that without much of the cost. I hope both succeed so that there is a gradient of capability from the low end to the high end, and a real move off of the duopoly we have now.

                                                  1. 4

                                                    Interesting point about the switches.

                                                    I think Pine has done better than Purism working to get drivers for their components supported by the upstream kernel. I think they’ve also done better getting help out to the various distributions when it comes to supporting the platform. By not having their own distro but getting hardware into developers’ hands, there is a whole ecosystem now. I think if it had been left to purism, you’d have one distro (PureOS) whose development is mostly done behind closed doors plus a couple nice contributions to mobile GNOME.

                                                    In particular, they seemed to have zero interest in upstreaming the PureOS kernel patchset before Pine came along.

                                                    I also hope both succeed, but I’m glad to see a wide-open development model making more of a play.

                                                    1. 7

                                                      The development of PureOS appears to be done in the open; the contribution of libhandy for GNOME was essential to making most of the apps work well in that form factor, and Purism have been supportive of KDE and UbuntuTouch as well. Not sure where the impression of “zero interest in upstreaming the PureOS kernel patchset” comes from or that the pinephone had an influence on that… my impression was the opposite. It’s never fun to maintain forks of the kernel when it’s not necessary, and resources are already tight and heavily invested in the rest of the software stack.

                                                      Purism has made a lot of missteps around communication especially with respect to shipping devices to backers. I haven’t observed any missteps around their commitment to using completely free software with no binary blobs required and getting RYF certification.

                                                      1. 2

                                                        What I meant when I said that development was behind closed doors was that when I visit

                                                        https://pureos.net/

                                                        I can’t find any source control repos, only a bunch of source packages. Which is fine, and still free, but not IMO open development. (That’s not some kind of moral failing, it’s just less interesting to me.)

                                                        My impression about their interest in mainline kernels came from unresponsiveness to inquiries about just that. There didn’t seem to be much movement that direction until just after Pine started booting mainline kernels :). Lack of resources could masquerade as disinterest, for sure, though and maybe it was just that.

                                                        They certainly do seem 100% committed to complete freedom and blob free operation, and that’s excellent. It’s important to have more hardware in the world that works that way, and I think the level of interest in their operation will only convince more people to try building that.

                                                        1. 6

                                                          pureos.net

                                                          Check out https://source.puri.sm/public

                                                          1. 3

                                                            That is dramatically better than the source link on the front of the PureOS site. Thanks.

                                                  2. 3

                                                    I can relate to the hesitance about making one of these devices your daily driver. What in particular is stopping you? Personally, I’d really want to be sure I can get ample battery life and that all my favorite apps can run, like Discord and Gmail. Obvjously, it also shouldn’t drop calls, fail to receive texts, or anything like that, either

                                                    1. 4

                                                      Last time I checked in, the call, text and MMS functionality was just not ready for prime time. I know that’s been improving quickly, but I haven’t squinted too hard to see where it is. For me to make it a daily driver, I’d need:

                                                      1. Rock solid phone calls
                                                      2. Extremely reliable SMS/MMS receipt
                                                      3. Good headset support
                                                      4. Mostly reliable SMS/MMS sending
                                                      5. Very good 4G data support
                                                      6. Ability for another device to reliably tether/use the phone as a hotspot
                                                      7. A battery that goes an entire workday without needing a charge when being used for voice calls, SMS/MMS and some light data usage

                                                      I’ve heard 1,2,3 were not quite there. 4 is supposedly there for SMS but not MMS, which last time I looked would keep me from using it on some group threads. I believe 5 is there and suspect 6 is just fine. 7 is probably good enough given the swappable, easy-to-find battery.

                                                      When it comes to apps on the phone itself, GPS would be nice to have, but as long as there’s a browser that is somewhat usable, I could stand to tether an iPad or Android tablet until app coverage was robust. I prefer to work from a laptop or tablet anyway. I’d also like to have a decent camera on my phone, but that’s not a hard requirement for me to daily drive one.

                                                      1. 6

                                                        As someone who has not used the sms, MMS, or voice features of any of my devices in a decade, it’s good to be reminded that some people still use these features.

                                                      2. 2

                                                        Can it run Employer mandated apps? Whether you’re delivering food or an engineer, they’re a thing now. Plus whatever app your local government mandates you put on your phone to check COVID-related restrictions.

                                                        To be honest, I think that for most people, the possibility of not owning a phone running one of the two major platforms is long gone.

                                                        1. 16

                                                          A couple of points are that many employers are supportive of variations of GNU/Linux. If yours isn’t, then really consider finding one that better aligns with your values.

                                                          When governments mandate apps there must really be a push to say loudly and clearly that proprietary applications are not acceptable. Quietly accepting and using a Google or Apple device means that the line will keep shifting in the wrong direction. For many (most? really all?) there is still the possibility of not owning a phone from Google or Apple and participating fully in society. It won’t stay that way unless people demand it.

                                                          1. 8

                                                            Of course employers are supportive of GNU/Linux - when it powers their servers. When it starts to interfere with their employees’ ability to log in to the network, review their schedule or attend meetings, you will see their support dry up quickly.

                                                            Not owning a Googapple phone is equivalent to not owning a phone as far as policy makers are concerned. Yes, your accessibility is considered, along with that of the elderly, homeless and poor. The notion of an employable person not owning one is increasingly alien to them.

                                                            1. 6

                                                              This comment should be boosted, especially for the fact that we are getting closer to the world where only Google or Apple is accepted. This is why I want to support Pine, even if their stuff is not ready.

                                                            2. 11

                                                              Can it run Employer mandated apps?

                                                              I would strongly recommend refusing to allow any company stuff on your private property. Not only is it likely to be spyware, but like, it is also not your problem to do their IT provisioning for them.

                                                              1. 3

                                                                It’s not your problem to provision motor vehicles for your employer either, but for many people, using their private car for work isn’t just normal, it’s the cornerstone of their employability.

                                                                1. 3

                                                                  At least with cars (except for commute to/from the workplace) you can generally get reimbursed for the mileage and it isn’t as likely to be the spyware.

                                                                  But even then, I’d say take advantage of the labor market and start fighting back against them pushing the costs on you.

                                                              2. 5

                                                                I’ve never had an employer or government mandate any mobile app. They can’t even usually mandate that you have a mobile device, unless they are providing one.

                                                                I know lots of people who run various apps that make their employer or government interactions more convenient, but never were they mandatory.

                                                                1. 4

                                                                  I’ve had an employer mandate that I either, at my option, accept their app on my device or carry their device and use it. I chose to carry two devices, but I understand why my colleagues chose to install the “mandated” apps instead.

                                                                  1. 5

                                                                    Yeah, if they offer me a device I’m always going to take it. No work shit on personal devices ever, but also why would I not take an extra device to have around?

                                                                2. 3

                                                                  I don’t really have any mandated apps other than OTP authenticators, but there’s a lot I’d miss (i.e quickly sending a message on Slack, or whatever services I use for pleasure; plus stuff like decent clients for whatever service). I could go without, but it certainly wouldn’t be a daily driver.

                                                                  What I might miss more is the stuff other than third-party apps/ecosystem: the quality of the phone and the OS itself, and if they meet my needs. I doubt Pine will make something sized like my 12 mini, or if Plasma Active/phosh will hit the same quality of mouthfeel as iOS (which as a Windows Phone 7/8 refugee, has good mouthfeel since they copied live tiles)

                                                                  1. 1

                                                                    I’m not sure. I remember hearing one of the Linux phones supported Android apps now

                                                                    1. 1

                                                                      I strongly suspect this “Pro” will have enough oomph to run anbox rather nicely. It runs on the current pinephones, but I don’t think it runs particularly well.

                                                                      I don’t know how much of the sensors and other bits (that, say, a ridesharing driver’s app might need) are exposed via Anbox on a pinephone. I also don’t know how much of the google play services stack works in that environment.

                                                                  2. 1

                                                                    The decision to maintain the original PinePhone’s screen resolution of 1440×720 was made early on; higher resolution panels consume more power and increase SoC’s load, resulting in shorter battery life and higher average thermals. A few extra pixels aren’t worth it.

                                                                    Immediately turned me off. High resolution displays are what make these phones satisfactory entertainment devices as well as just communications devices.

                                                                1. 3

                                                                  It’s even worse. Most users are unable to input URL when prompted verbally. They use the search field on their home page.

                                                                  1. 2

                                                                    Yes, it’s pretty much the 60+ method in my impression. I hope kids these days know better.

                                                                    But even when you know the difference, there is one more hurdle: My memory, at least, is not just case insensitive, but TLD insensitive: Was it .com, .org or .net again? Sometimes, I guess wrong, and find a shady spam site insetad. I need a TLD resolver, and I use both search engines and Wikipedia for that.

                                                                    1. 3

                                                                      High school computer science teacher here, and I can assure you the kids these days do not know better, unfortunately.

                                                                      1. 2

                                                                        More like 50+, at least around me. They also love to share their passwords with me. :shrug:

                                                                        1. 1

                                                                          I really hate the TLD proliferation. Now you can’t even just assume a company is .com, now it might be .pizza. Or one of those godawful dots in the middle of the word. Those are the worst.

                                                                          I’ve used search for things I was even quite confident of just because of that.

                                                                      1. 25

                                                                        Fascinating read. Audio was the thing that made me switch from Linux to FreeBSD around 2003. A bit before then, audio was provided by OSS, which was upstream in the kernel and maintained by a company that sold drivers that plugged into the framework. This didn’t make me super happy because those drivers were really expensive. My sound card cost about £20 and the driver cost £15. My machine had an on-board thing as well, so I ended up using that when I was running Linux.

                                                                        A bit later, a new version of OSS came out, OSS 4, which was not released as open source. The Linux developers had a tantrum and decided to deprecate OSS and replace it with something completely new: ALSA. If your apps were rewritten to use ALSA they got new features, but if they used OSS (as everything did back then) they didn’t. There was only one feature that really mattered from a user perspective: audio mixing. I wanted two applications to be able both open the sound device and go ‘beep’. I think ALSA on Linux exposed hardware channels for mixing if your card supported it (my on-board one didn’t), OSS didn’t support it at all. I might be misremembering and ALSA supported software mixing, OSS only hardware mixing. Either way, only one OSS application could use the sound device at the time and very few things had been updated to use ASLA.

                                                                        GNOME and KDE both worked around this by providing userspace sound mixing. These weren’t great for latency (sound was written to a pipe, then at some point later the userspace sound daemon was scheduled and then did the mixing and wrote the output) but they were fine for going ‘bing’. There was just one problem: I wanted to use Evolution (GNOME) for mail and Psi (KDE) for chat. Only one out of the KDE and GNOME sound daemons could play sound at a time and they were incompatible. Oh, and XMMS didn’t support ALSA and so if I played music the neither of them could do audio notifications.

                                                                        Meanwhile, the FreeBSD team just forked the last BSD licensed OSS release and added support for OSS 4 and in-kernel low-latency sound mixing. On FreeBSD 4.x, device nodes were static so you had to configure the number of channels that it exposed but then you got /dev/dsp.0, /dev/dsp.1, and so on. I could configure XMMS and each of the GNOME and KDE sound daemons to use one of these, leaving the default /dev/dsp (a symlink to /dev/dsp.0, as I recall) for whatever ran in the foreground and wanted audio (typically BZFlag). When FreeBSD 5.0 rolled out, this manual configuration went away and you just opened /dev/dsp and got a new vchan. Nothing needed porting to use ALSA, GNOME’s sound daemon, KDE’s sound daemon, PulseAudio, or anything else: the OSS APIs just worked.

                                                                        It was several years before audio became reliable on Linux again and it was really only after everything was, once again, rewritten for PulseAudio. Now it’s being rewritten for PipeWire. PipeWire does have some advantages, but there’s no reason that it can’t be used as a back end for the virtual_oss thing mentioned in this article, so software written with OSS could automatically support it, rather than requiring the constant churn of the Linux ecosystem. Software written against OSS 3 20 years ago will still work unmodified on FreeBSD and will have worked every year since it was written.

                                                                        1. 8

                                                                          everything was, once again, rewritten for PulseAudio. Now it’s being rewritten for PipeWire

                                                                          Luckily there’s no need for such a rewrite because pipewire has a PulseAudio API.

                                                                          1. 1

                                                                            There was technically no need for a rewrite from ALSA to PulseAudio, either, because PulseAudio had an ALSA compat module.

                                                                            But most applications got a PulseAudio plug-in anyway because the best that could be said about the compat module is that it made your computer continue to go beep – otherwise, it made everything worse.

                                                                            I am slightly more hopeful for PipeWire, partly because (hopefully) some lessons have been drawn from PA’s disastrous roll-out, partly for reasons that I don’t quite know how to formulate without sounding like an ad-hominem attack (tl;dr some of the folks behind PipeWire really do know a thing or two about multimedia and let’s leave it at that). But bridging sound stacks is rarely a simple affair, and depending on how the two stacks are designed, some problems are simply not tractable.

                                                                            1. 2

                                                                              One could also say that a lot of groundwork was done by PulseAudio, revealing bugs etc so the landscape that PipeWire enters in 2021 is not the same that PulseAudio entered in 2008. For starters there’s no Arts, ESD etc. anymore, these are long dead and gone, the only thing that matters these days is the PulseAudio API and the JACK API.

                                                                              1. 3

                                                                                I may be misremembering the timeline but as far as I remember it, aRts, ESD & friends were long dead, gone and buried by 2008, as alsa had been supporting proper (eh…) software mixing for several years by then. aRts itself stopped being developed around 2004 or so. It was definitely no longer present in KDE 4, which was launched in 2008, and while it still shipped with KDE 3, it didn’t really see much use outside KDE applications anyway. I don’t recall how things were in Gnome land, I think ESD was dropped around 2009, but pretty much everything had been ported to canberra long before then.

                                                                                I, for one, don’t recall seeing either of them or using either of them after 2003, 2004 or so, but I did have some generic Intel on-board sound card, which was probably one of the first ones to get proper software mixing support on alsa, so perhaps my experience wasn’t representative.

                                                                                I don’t know how many bugs PulseAudio revealed but the words “PulseAudio” and “bugs” are enough to make me stop consider going back to Linux for at least six months :-D. The way bug reports, and contributors in general, technical and non-technical alike were treated, is one of the reasons why PulseAudio’s reception was not very warm to say the least, and IMHO it’s one of the projects that kickstarted a very hostile and irresponsible attitude that prevails in many Linux-related open-source projects to this day.

                                                                          2. 4

                                                                            I might be misremembering and ALSA supported software mixing, OSS only hardware mixing.

                                                                            That’s more like it on Linux. ALSA did software mixing, enabled by default, in a 2005 release. So it was a pain before then (you could enable it at least as early as 2004, but it didn’t start being easy until 1.0.9 in 2005)… but long before godawful PulseAudio was even minimally usable.

                                                                            BSD did the right thing though, no doubt about that. Linux never learns its lesson. Now Wayland lololol.

                                                                            1. 4

                                                                              GNOME and KDE both worked around this by providing userspace sound mixing. These weren’t great for latency (sound was written to a pipe, then at some point later the userspace sound daemon was scheduled and then did the mixing and wrote the output) but they were fine for going ‘bing’.

                                                                              Things got pretty hilarious when you inevitably mixed an OSS app (or maybe an ALSA app, by that time? It’s been a while for me, too…) and one that used, say, aRTs (KDE’s sound daemon).

                                                                              What would happen is that the non-aRTs app would grab the sound device and clung to it very, very tight. The sound daemon couldn’t play anything for a while, but it kept queuing sounds. Like, say, Gaim alerts (anyone remember Gaim? I think it was still gAIM at that point, this was long before it was renamed to Pidgin).

                                                                              Then you’d close the non-aRTs app, and the sound daemon would get access to the sound card again, and BAM! it would dump like five minutes of gAIM alerts and application error sounds onto it, and your computer would go bing, bing, bing, bang, bing until the queue was finally empty.

                                                                              1. 2

                                                                                I’d forgotten about that. I remember this happening when people logged out of computers: they’d quit BZFlag (yes, that’s basically what people used computers for in 2002) and log out, aRTs would get access to the sound device and write as many of the notification beeps as it could to the DSP device before it responded to the signal to quit.

                                                                                ICQ-inspired systems back then really liked notification beeps. Psi would make a noise both when you sent and when you received a message (we referred to IM as bing-bong because it would go ‘bing’ when you sent a message and ‘bong’ when you received one). If nothing was draining the queue, it could really fill up!

                                                                                1. 1

                                                                                  Then you’d close the non-aRTs app, and the sound daemon would get access to the sound card again, and BAM! it would dump like five minutes of gAIM alerts and application error sounds onto it, and your computer would go bing, bing, bing, bang, bing until the queue was finally empty.

                                                                                  This is exactly what happens with PulseAudio to me today, provided the applications trying to play the sounds come from different users.

                                                                                  Back in 2006ish though, alsa apps would mix sound, but OSS ones would queue, waiting to grab the device. I actually liked this a lot because I’d use an oss play command line program and just type up the names of files I want to play. It was an ad-hoc playlist in the shell!

                                                                                2. 4

                                                                                  This is just an example of what the BSDs get right in general. For example, there is no world in which FreeBSD would remove ifconfig and replace it with an all-new command just because the existing code doesn’t have support for a couple of cool features - it gets patched or rewritten instead.

                                                                                  1. 1

                                                                                    I’m not sure I’d say “get right” in a global sense, but definitely it’s a matter of differing priorities. Having a stable user experience really isn’t a goal for most Linux distros, so if avoiding user facing churn is a priority, BSDs are a good place to be.

                                                                                    1. 1

                                                                                      I don’t know; the older I get the more heavily I value minimizing churn and creating a system that can be intuitively “modeled” by the brain just from exposure, i.e. no surprises. If there are architectural reasons why something doesn’t work (e.g. the git command line), I can get behind fixing it. But stuff that just works?

                                                                                  2. 4

                                                                                    I guess we can’t blame Lennart for breaking audio on Linux if it was already broken….

                                                                                    1. 7

                                                                                      You must be new around here - we never let reality get in the way of blaming Lennart :-/

                                                                                      1. 2

                                                                                        Same as with systemd, there were dozens of us where everything worked before. I mean, I mostly liked pulseaudio because it brought a few cool features, but I don’t remember sound simply stopping to work before. Sure, it was complicated to setup, but if you didn’t change anything, it simply worked.

                                                                                        I don’t see this as blaming. Just stating the fact that if it works for some people, it’s not broken.

                                                                                      2. 3

                                                                                        Well, can’t blame him personally, but the distros who pushed that PulseAudio trash? Absolutely yes they can be blamed. ALSA was fixed long before PA was, and like the parent post says, they could have just fixed OSS too and been done with that before ALSA!

                                                                                        But nah better to force everyone to constantly churn toward the next shiny thing.

                                                                                        1. 4

                                                                                          ALSA was fixed long before PA was, and like the parent post says, they could have just fixed OSS too and been done with that before ALSA!

                                                                                          Huh? I just setup ALSA recently and you very much had to specifically configure dmix, if that’s what you’re referring to. Here’s the official docs on software mixing. It doesn’t do anything as sophisticated as PulseAudio does by default. Not to mention that on a given restart ALSA devices frequently change their device IDs. I have a little script on a Void Linux box that I used to run as a media PC which creates the asoundrc file based on outputs from lspci. I don’t have any such issue with PulseAudio at all.

                                                                                          1. 3

                                                                                            dmix has been enabled by default since 2005 in alsa upstream. If it wasn’t on your system, perhaps your distro changed things or something. The only alsa config I’ve ever had to do is change the default device from the hdmi to analog speakers.

                                                                                            And yeah, it isn’t sophisticated. But I don’t care, it actually works, which is more than I can say about PulseAudio, which even to this day, has random lag and updates break the multi-user setup (which very much did not just work). I didn’t want PA but Firefox kinda forced my hand and I hate it. I should have just ditched Firefox.

                                                                                            Everyone tells me the pipewire is better though, but I wish it could just go back to the default alsa setup again.

                                                                                            1. 6

                                                                                              Shrug, I guess in my experience PulseAudio has “just worked” for me since 2006 or so. I admit that the initial rollout was chaotic, but ever since it’s been fine. I’ve never had random lag and my multi-user setup has never had any problems. It’s been roughly 15 years, so almost half my life, since PulseAudio has given me issues, so at this point I largely consider it stable, boring software. I still find ALSA frustrating to configure to this day, and I’ve used ALSA for even longer. Going forward I don’t think I’ll ever try to use raw ALSA ever again.

                                                                                          2. 1

                                                                                            I’m pretty sure calvin is tongue in cheek referencing that Lennart created PulseAudio as well as systemd.

                                                                                        2. 3

                                                                                          I cannot up this comment more. The migration to ALSA was a mess, and the introductions of Gstreamer*, Pulse*, or *sound_daemon fractured the system more. Things in BSD land stayed much simpler.

                                                                                          1. 3

                                                                                            I was also ‘forced’ out of Linux ecosystem because of mess in sound subsystem.

                                                                                            After spending some years on FreeBSD land I got hardware that was not FreeBSD supported at that moment so I tried Ubuntu … what a tragedy it was. When I was using FreeBSD I got my system run for months and rebooted only to install security updates or to upgrade. Everything just worked. Including sound. In Ubuntu land I needed to do HARD RESET every 2-3 days because sound will went dead and I could not find a way to reload/restart anything that caused that ‘glitch’.

                                                                                            Details here:

                                                                                            https://vermaden.wordpress.com/2018/09/07/my-freebsd-story/

                                                                                            1. 1

                                                                                              From time to time I try to run my DAW (Bitwig Studio) in Linux. A nice thing about using DAWs from Mac OS X is that, they just find the audio and midi sources and you don’t have to do a lot of setup. There’s a MIDI router application you can use if you want to do something complex.

                                                                                              Using the DAW from Linux, if it connects via ALSA or PulseAudio, mostly just works, although it won’t find my audio interface from PulseAudio. But the recommended configuration is with JACK, and despite reading the manual a couple times and trying various recommended distributions, I just can’t seem to wrap my head around it.

                                                                                              I should try running Bitwig on FreeBSD via the Linux compatibility layer. It’s just a Java application after all.

                                                                                              1. 7

                                                                                                Try updating to Pipewire if your distribution supports it already. Then you get systemwide Jack compatibility with no extra configuration/effort and it doesn’t matter much which interface the app uses. Then you can route anything the way you like (audio and MIDI) with even fewer restrictions than MacOS.

                                                                                                1. 1

                                                                                                  I’ll give that a try, thanks!

                                                                                            1. 3

                                                                                              just like you don’t write audio applications directly to the ALSA API anymore

                                                                                              Isn’t that a mistake we’ve been paying for for years? Even ALSA itself (vs just fixing/improving OSS as has been done elsewhere) was a mistake in hindsight, but “Oh let’s add a new layer on top instead of fixing the current one” has only ever resulted in years of things being broken.

                                                                                              1. 5

                                                                                                I don’t have a magic crystal ball, but I think we could end up in a worse situation if we just bloted alsa/oss with features. Right now we have a nice split where alsa mostly deals with real devices and another layer deals with routing / mixing / dynamic updates. If we ended up with effectively oss+pa in one project, maybe we’d either not recover or have to rewrite everything to fix it. Now we’re pretty much moving from alsa+pa to alsa+pw without the base layer changing much. I don’t think that’s a bad situation to be in.

                                                                                                1. 1

                                                                                                  But if you don’t need those other features, why not just use the ALSA calls? Even if it goes through the pipewire virtual device or whatever, it seems absurd to constantly rewrite everything when you could just target the base.

                                                                                                  1. 2

                                                                                                    I would prefer to use an API that is high-level and allows me to easily port my application to other environments, rather than use something that is low-level and Linux-specific. In that case the argument is moot; I’m targeting neither alsa nor PA nor PW.

                                                                                              1. 8

                                                                                                A local font stack is all well and good, but Helvetica and Arial, et al are just…well…boring.

                                                                                                This is my only disagreement with the article. I prefer to just use the user’s default font. Sure, that is boring but I personally don’t find much value in every site having their own “exciting” font. I just want to see my nice, readable default font almost everywhere. (Some things like games have a reasonable excuse to use their own.)

                                                                                                So drop the font stack altogether and just leave the default. Or if you really must font: sans-serif (or serif). Or the newfangled ui-sans-serif (if I remember that correctly).

                                                                                                Of course the downside is that a lot of browsers use garbage default fonts by default…

                                                                                                1. 8

                                                                                                  Of course the downside is that a lot of browsers use garbage default fonts by default…

                                                                                                  This is the real underlying problem. The overwhelming vast majority of users don’t even know they can change the default font much less know how to.

                                                                                                  1. 6

                                                                                                    100%. Which is super disappointing because it would take browsers very little effort to fix.

                                                                                                    Firefox doesn’t even default to my system font by default (which is quite nice) so I need to teach it to follow my system font which ~0% of users will do.

                                                                                                  2. 7

                                                                                                    Helvetica and Arial, et al are just…well…boring.

                                                                                                    Boring is good! Most of the time, typography’s job is to get out of the way. Browser-default sans-serif is usually what you want, with a slight bump to the size.

                                                                                                    1. 4

                                                                                                      If everyone needs to bump the size maybe we should petition browsers to make the default bigger…

                                                                                                      1. 2

                                                                                                        Agree! font-size: 16pt; is a much better default.

                                                                                                    2. 4

                                                                                                      I just want to see my nice, readable default font almost everywhere.

                                                                                                      This is why I disable custom fonts entirely i my browser. Makes me laugh when a bad website (looking at anything created by Google) uses idiotic icon fonts, but whatever, those sites aren’t worth using anyway.

                                                                                                      1. 2

                                                                                                        I’ve done this on-and-off but I’m not completely sold. Luckily icon fonts are somewhat falling out of style but I think there are legitimate uses for custom fonts, especially for things that are more wacky and fun. I think it is just a shame that they are abused (IMHO) on just about every website.

                                                                                                        1. 4

                                                                                                          Not somewhat. Fonts for icons have not been a recommended practice in since 2014 when the people shifted to SVG icons via symbols. Prevalence is likely devs that learned about icon fonts at one point, especially in the past when IE compatibility took away many options, and those people do not do enough front-end to bother keeping up with most trends.

                                                                                                      2. 3

                                                                                                        The people who think to change their browser’s default font are probably the same people who can figure out how to force websites to use the default font.

                                                                                                        Shipping a font with a site is the same as any other styling: helpful for the average user, overridable by the power user.

                                                                                                        1. 2

                                                                                                          I’m kind of interested right now in both improving my website’s typography and getting rid of things like background images and web fonts. The page is already pretty light, but it can be lighter, and I’m questioning the value of the fonts I’m using. I do want to exercise some choice in fonts, though. The ui-sans-serif (etc) look like good options, but so far they’re only supported on Safari. I’m probably going to do some research on a local font stack that doesn’t include awful fonts like Helvetica and Times New Roman, has a reasonable chance of working cross-platform, and falls back to serif, sans-serif, and monospace.

                                                                                                          1. 4

                                                                                                            I don’t know that many people think Helvetica is “awful”.

                                                                                                            Just cut things. Cut the background images entirely; replace with a nice single color. Start by cutting all the web fonts: specify serif and sans-serif and no more than four or five sizes of each. Make sure your margins are reasonable and text column widths are enjoyable. How many colors are you using? Is there enough contrast?

                                                                                                            Once you’ve stripped everything back to a readable, comfortable page, see what you actually need to distinguish yourself rather that trying a bunch of trends. What image are you trying to project? Classic and authoritative? Modern? Comedic? Simple? Fashionable? Pick one approach and try to align things to that feel.

                                                                                                            1. 1

                                                                                                              Helvetica and Times New Roman are de facto standards for a reason. They’re solid, utilitarian typefaces. I wish more sites used them.

                                                                                                          1. 3

                                                                                                            Oh yes, this technique is very useful. My gui library uses it to inject javascript-style event handlers. Here’s the code

                                                                                                            https://github.com/adamdruppe/arsd/blob/01e8b3a355f5585c4198fd1f2b2c9059a5a8312b/minigui.d#L2705

                                                                                                            Which calls this function:

                                                                                                            https://github.com/adamdruppe/arsd/blob/01e8b3a355f5585c4198fd1f2b2c9059a5a8312b/minigui.d#L2576

                                                                                                            Which actually forwards back to a virtual method in the D class for future customization. But if you scoll down a little bit there’s also this bit of magic:

                                                                                                            if(SimpleWindow.triggerEvents(hWnd, iMessage, wParam, lParam, pos[0], pos[1], (*te).parentWindow.win) || !lastDefaultPrevented)
                                                                                                            					return CallWindowProcW((*te).originalWindowProcedure, hWnd, iMessage, wParam, lParam);
                                                                                                            

                                                                                                            Which is a bit hacky, but the triggerEvents will send it through as my low-level event struct, which is then processed into a high-level Event class, which user code can process JS-style

                                                                                                            listBox.addEventListener("click", (e) {
                                                                                                               e.preventDefault();
                                                                                                            });
                                                                                                            

                                                                                                            To override the normal window processing.

                                                                                                            It actually works surprisingly well and I do this to all windows; back in the first link where I do the SetWindowLong, you will notice EnumChildWindows(p.hwnd, &childHandler, cast(LPARAM) cast(void*) p);, that is, it does the override hook recursively on any automatically-created children too.

                                                                                                            A bit crazy but like I said, it really does work surprisingly well and wasn’t actually that hard to cram in. I actually mostly like the Windows API. People call me a lying troll for saying that, but it is pretty complete so it helps you get a lot of work done, and it offers these hooks so you can get around it if it happens to be in your way. And most the quirks actually do make sense once you get to know them.

                                                                                                            I legitimately think Microsoft have done a pretty solid job.

                                                                                                            1. 6

                                                                                                              A bit crazy but like I said, it really does work surprisingly well and wasn’t actually that hard to cram in. I actually mostly like the Windows API. People call me a lying troll for saying that, but it is pretty complete so it helps you get a lot of work done, and it offers these hooks so you can get around it if it happens to be in your way. And most the quirks actually do make sense once you get to know them.

                                                                                                              It’s funny to me I’ve been using the Linux desktop for what, 12 years? And I still don’t really know how to write a desktop application - it’s overwhelming and the toolkits seem mostly bad. The furthest I got was Gtk#. Meanwhile, I’ve doing Win32 C programming for 2-3 years (albeit some high-level experience w/ Windows Forms before that), I’d call myself intermediate at best with it, but I can make useful applications with it. It’s actually a well designed API (especially compared to its contemporaries), albeit one with little magic. Ironically, Windows still has the “you can choose several toolkits” problem, but for the most part, they’re just dipping mustards around Win32, and you can feel confident that if you pick one, even if it doesn’t get showered with love, it’ll do what you want for years. I can’t say the same with the X11 parts bin.

                                                                                                              I’ve got more Windows API related nuclear takes, if anyone’s curious…

                                                                                                              1. 3

                                                                                                                I used Qt for a while back around when version 4.1 was coming out and I didn’t hate it, but it wasn’t great on Windows and besides, using it from D (which I switched basically everything to in 2007sih) just wasn’t very practical. And I really hate GTK as a user. Its api isn’t too bad, with the C interface and the XML interface definitions you can use it from other languages pretty easily. But on Windows it is pretty bad and even on Linux like… I just hate it. That horrible file dialog really drives me nuts, among other things.

                                                                                                                I also got meh about sdl.dll so…. I actually decided to write all my own stuff just on top of xlib and the OS. All the code scattered in here https://github.com/adamdruppe/arsd among many other things. But the main low-level file is simpledisplay.d which is a Win32 implementation on Windows and generally a X simulation of it on Linux, though in some cases I adapted the Windows API to better fit X (like async callback based get clipboard).

                                                                                                                Then for the higher level controls like buttons and checkboxes, I started writing minigui.d which is kinda the same - Win32 controls there with kinda (but not exactly, it is custom so I embrace that in some ways) simulated versions on X all done myself. And yeah it has grown to another 12,000 lines lately…. there’s just soooo many little details to get right to make it feel decent.

                                                                                                                Having done all this myself gives me a perspective I don’t see much. There’s actually a lot I like about X too, and getting this deep has given me a decent view on its history (and X generally maintains compatibility pretty well too actually, but it does so little by itself in terms of high level controls that this doesn’t help applications much as most everyone uses a toolkit and THOSE break every other week). I can see the extensions and version history in some of the specs and understand where they were coming from as I develop my own thing. Always want to keep things “simple” and “mini” but eventually use cases make you do more and more and before you know it, you have 32,000 lines of code lol.

                                                                                                                But seriously, and comparing it against the Windows functions too, you can see a lot of the same cycles. The X drag and drop spec started out as a kind of simplification of the Windows one… but before long, turned into basically a clone, just with more async and distributed aspects to fit into X’s networked and mechanism-not-policy model (which there’s a lot I like about, like the drag and drop or clipboard protocols being lazy is really cool. “Copy” side doesn’t actually copy, it just advertises that it has something and can offer in a list of formats. Paste side then asks for it to actually be delivered as one of those formats, and the “copy” side can do it on-demand and stream the data over. And if the programs are written well on both sides, the streamed data is part of the event loop, meaning pasting huge videos or something doesn’t lock up the UI; you can do a progress bar and offer cancellations and such. That’s legitimately really nice. Though most things don’t do much with that underlying potential ugh.)

                                                                                                                Anyway, using X makes me appreciate Win32 a lot more because it is so much more complete. But I still actually kinda like X too, especially I love doing things myself :) (ps don’t ask me what i think about wayland unless you want an angry, profanity laden rant.)

                                                                                                                1. 2

                                                                                                                  Always down for the nuclear takes.

                                                                                                                  1. 6

                                                                                                                    Windows is more meaningfully extensible than the X11 toybox; things more useful than silly applets like conky or dmenu. Sounds crazy, but it’s true.

                                                                                                                    A while back, I wrote a shell extension (which seemed hard at the time, but after doing it, I have a much better grasp on it, and tbh if I had context before, it would have been easier). After I wrote it, I get it for free in both the file manager and any file dialogs in applications I open. And it’s based on common APIs that other things share.

                                                                                                                    How would I accomplish that on Linux? I might be able to hack at and patch my desktop/toolkit (assuming I know what layer needs modified), but what about if I have an application with a different toolkit? Maybe the toolkit had the hooks for it (KDE sounds like it might have), but I suspect those have rotted by now. How do I keep my patch up to date, or build it on my normal distro like Debian?

                                                                                                                    In the Windows world, this kind of extensiblity was anticipated and well supported. The problem was the lacking documentation to deal with that complexity and unambitious developers. And I didn’t even need the source to Windows to make it.

                                                                                                                    1. 2

                                                                                                                      I’d both agree and disagree. I used a custom shell on Windows for a while and tweaked a lot of settings that was really cool, but like it still kept raising windows when I didn’t want it to. So it depends on what you want to change. But for the majority of things I think I agree with you.

                                                                                                                      So I also kinda have that feeling about scripting. I think Windows’ scripting is really underrated because there’s a LOT of COM automation you can do, including through the windows scripting host, that puts a lot of linux app’s scriptability to shame. But I hesitate to take a strong stance on this because I haven’t actually done a whole lot of Windows scripting, so there’s probably lots of filth I just haven’t seen due to inexperience.

                                                                                                                2. 2

                                                                                                                  Heh, I feel like every C++ app I’ve touched that doesn’t use MFC or OWL basically hits on what you’re doing. The strings instead of methods is admittedly different, but the rest is familiar.

                                                                                                                  And I’m with you: I honestly think Windows’ APIs are overall very well-designed. The issues are more the amazing commitment to back compact leaving cruft, the lack of foresight resulting in FooBarEx and the like for early calls, and the occasional just absurd API (early DirectX, the tracing APIs, etc.). Even COM is a great API.

                                                                                                                  1. 3

                                                                                                                    That amazing commitment is absolutely worth the cruft though. I first learned Win32 programming - actually around 2003ish - from an old Windows 95 help file I downloaded to a floppy disk. (I had a hand-me-down computers with no internet access, so I’d take disks to the school, download stuff, then bring them back home.) Obviously Windows 95 was a bit old by 2003…. but virtually all the stuff in that old file not only still applied as learning material, it all still actually worked practically! Indeed, most that stuff still works today.

                                                                                                                    Which like the link says is actually really nice since sometimes the old, limited functions are actually exactly what you need and a lot simpler to use. And, of course, having old programs you can pull up and still actually use is excellent for so many reasons.

                                                                                                                    1. 3

                                                                                                                      Just to be clear, you and I are agreeing vigorously. I was just saying, “I think Windows gets a bad rap due to these reasons.” (I do, however, sincerely believe that the tracing API in Windows is just absolutely bananas. That part’s a complete pile, and I’m looking forward to the eBPF and dtrace stuff coming in Windows 11 as a possible way out of the madness.)

                                                                                                                      1. 3

                                                                                                                        Unless you’re Bruce Dawson, of course. That guy makes makes ETW look easy.

                                                                                                                        1. 2

                                                                                                                          indeed. I’m just using the excuse to talk a little :P

                                                                                                                      2. 1

                                                                                                                        One of the major reasons I didn’t do the COM-based drop target is because pretty much every single piece of documentation assumes “yeah, just inherit COleDropTarget in your CView”, which would be great if I were using MFC. I think I understand how to do it from rawdog Win32 now, but it is a tricky when I don’t necessarily need the benefits it has.

                                                                                                                        1. 1

                                                                                                                          Yeah, it is kinda annoying when the docs assume MFC. I’ve written tons of low level libraries in D and have similar pains. Now D is different than C in that it actually has some built-in COM support; if you write a class that inherits from IDispatch, the language will help you out a little by wiring together the vtables for you. Then the language itself doesn’t do QueryInterface but you can metaprogram that if you want so it isn’t too hard to use. In C, of course, you’d have to do structs of function pointers you populate yourself. More tedious work but not fundamentally too different.

                                                                                                                          But a drop target isn’t too hard, here’s my COM class that forwards to an application-defined class:

                                                                                                                          https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L19539

                                                                                                                          then you call RegisterDragAndDrop with the hwnd. The Linux implementation was WAY more work (also in that file if you’re curious, just scroll down 100 or so lines)

                                                                                                                          The COM api and the html5 api are (not coincidentally given browser dnd history) very similar and it actually isn’t too hard to use. But not as easy as the drop files window message lol.

                                                                                                                          1. 2

                                                                                                                            It’s actually less the documentation and other people’s advice. I guess by the 2000s everyone was using C++ for Windows development!

                                                                                                                    1. 2

                                                                                                                      I think colors in the terminal and even syntax highlighting are overrated and often cause problems that don’t need to exist.

                                                                                                                      1. 4

                                                                                                                        It’s an arbitrary line, and often one drawn by the aesthetics of Unix retrofetishists. Likewise,

                                                                                                                        I think line drawing and even control characters are overrated and often cause problems that don’t need to exist.

                                                                                                                        And this is basically the same level of complexity, if not more so than colours - having to know where the cursor is and when not to move the cursor is far more complex than just changing some colours. (But making the terminal anything other than green-on-black is less 1337, isn’t it?)

                                                                                                                        The entire TTY subsystem should have been taken out back and shot decades ago due to the inane and inconsistent hacks required to make it usable, but now we’re stuck with and celebrate it instead. Even if you’re not like me who prefers bitmap/vector displays, it’s hard not to admit terminals could have been done a lot better. (The Unix Haters’ book covered this and contrasted w/ i.e. ITS and VMS’ approaches.)

                                                                                                                        edit: Syntax highlighting is a total non-sequitur here too.

                                                                                                                        1. 1

                                                                                                                          Its not about 1337 or not.

                                                                                                                          I just tried to disable most colors on the terminal and text editor and found it doesn’t make much difference. The main side effect was that things are easier to configure and have fewer problems when the color schemes don’t match my terminal.

                                                                                                                          Syntax highlighting is related because more and more programs are trying to backport the text editor color schemes to the terminal output of their commands.

                                                                                                                          If you like them, I don’t mind, I just think they are overrated - It is unclear what value they provide, I am unsure it actually makes scanning text output any easier.

                                                                                                                          1. 1

                                                                                                                            Yeah, I agree. Syntax highlighting randomly failed on one of my files a couple months ago and I just kept going without it and…. it really just makes very little difference. The file works just the same. I think highlighting is more about expectations for what a thing is supposed to look like; without it it looks unfinished if you have this expectation. But it doesn’t make a huge difference.

                                                                                                                            The horrible colors of ls is actually the #2 reason why I wrote my own terminal emulator (the #1 reason being making shift+page up work consistently when nesting attached sessions, C-a [ in gnu screen drives me nuts). I made mine adjust colors to the background so it doesn’t hurt my eyes. So if ls writes yellow on white, it makes it a dark yellow so I can actually read it. Similarly if it is blue on black, ti fixes it. Independent of application or anything else.

                                                                                                                            The colors now no longer make things worse. Idk if they really make it better.

                                                                                                                        2. 2

                                                                                                                          I think running a non-line oriented editor in a terminal is more trouble than it’s worth.

                                                                                                                          1. 1

                                                                                                                            I think running a non-line oriented editor in a terminal is more trouble than it’s worth.

                                                                                                                            If this is your genuine opinion great, if not, I don’t see why you made this comment.

                                                                                                                            I genuinely code both with and without syntax highlighting and don’t notice a difference. I suggest more people try it as it saves the burden of configuring text editors and dealing with misconfigured terminal color schemes.

                                                                                                                        1. 4

                                                                                                                          So between in-band information (like ANSI escape codes) and out-of-band information (like signals and ioctls), GOOD LUCK WRITING A TERMINAL EMULATOR.

                                                                                                                          Actually you don’t have to mess with the signals when writing a terminal emulator. The kernel does that. You just send the ioctl to inform the kernel that things changed (TIOCSWINSZ); Though you might send the signal yourself additionally. What’s annoying is if there’s another foreground process the signal goes to it then your other ones won’t necessarily be informed. My terminal emulator tries to hack this by resending the thing when the process changes… but that’s hard to do too since the terminal just gets pipes without necessarily having all the info.

                                                                                                                          The linux terminal is a mess. Frankly I wish it would die. But it also does useful things and has a huge ecosystem sigh.

                                                                                                                          1. 2

                                                                                                                            What is “the Linux terminal”? Honest question. Are you referring to terminal emulation? In which way is that Linux specific?

                                                                                                                            What would you do different? Do you mean that a text repl as an interface tot he system is a bad idea per se? Why? What do you suggest instead?

                                                                                                                            1. 18

                                                                                                                              What is “the Linux terminal”?

                                                                                                                              The abstract concept of terminals as used by Linux programs. So the fact that it is random sequences mixed in to a pipe where neither side knows much about the other, with the kernel in the middle doing its own thing.

                                                                                                                              Of course it isn’t actually Linux specific but I thought this was an easy and convenient way to communicate the ideas used there as opposed to the ideas used in a Windows console application or an X application, etc.

                                                                                                                              What would you do different?

                                                                                                                              Almost literally everything. It is awful from top to bottom. Everyone loves to hate the Windows console subsystem (mostly because the end-user ui was questionable until kinda recently, not even allowing convenient resizes (you had to go to the properties sheet instead of dragging the window like everything else? Bah!)), but the technical foundation was much nicer, with a considerably less error-prone input API, though the output API became a bit of a pain to use, it was also at least more reliable.

                                                                                                                              INPUT

                                                                                                                              I guess I’ll start there. Linux terminal input api is “read bytes from pipe”. The interpretation of those bytes is extremely complicated since it is technically undefined; it can change based on what terminal you have. Nowadays though most everyone emulates the xterm (which itself kinda emulates the VT100 among other things, but it is really xterm that sets the standard today), so that simplifies things a little. A little… rxvt is still pretty respectable but has a slightly different input sequence. And until recently, the Mac OS Terminal was slightly different too. And then different people’s xterm clones also can offer or not offer their own things.

                                                                                                                              But still, let’s say you just want to read xterm and call that good enough. The sequence is still a massively complicated state machine with very little consistency! The byte 27 means expect extra info… except when it doesn’t because the user just hit esc. Those sequences are variable length and the end character depends on what the next few characters were, so if you try to implement just a few and skip unknown ones… there be dragons. You can do it but even skipping unknown things takes a lot of preprogrammed knowledge. Once you do read a sequence successfully, their interpretation may depend on global settings in the terminal which can be left behind from the previous application. Fun.

                                                                                                                              Then once you decode it, various pieces of information are not even present. Want a key release event? Too bad. Want to know if it was enter or shift enter? Need an extension (and this is why most thing emulate xterm since at least then you can kinda standardize on extensions… but there’s no guarantee it is present and querying this is a pain even when it is possible, which it often isn’t).

                                                                                                                              Ever had a program crash then moving the mouse across the terminal outputs spam? Or find you type and nothing happens? now you know why. The terminal can’t tell the program crashed and reset itself, no, it is stuck with whatever random global state it was in then and the other application may not know how to interpret this data stream.

                                                                                                                              Contrast to the Windows console where input events come as structured data, creatively named an INPUT_RECORD struct. The length of these is told to you so you can skip them easily if you’re not interested. Extensions can now be easily added and applications won’t be lost. Much much nicer. Most gui things work like this too. So I’d take structured input data in my new system over the escape sequences on input. (Of course, it does burn a few extra bytes on the wire. Realistically they could have afforded this on the input even back in the physical hardware at 300 baud days but you can understand things were different then.)

                                                                                                                              Speaking of input events, the general terminal paradigm when programming the client application is to block for input. You know, scanf("%d", &a); printf("%d\n", a);. This isn’t necessarily bad - sure can be convenient - but it really does suck for anything more interactive. Most linux programs do some kind of event loop even with the terminal anyway. But then scanf() stops working. Now I hate scanf anyway, but again Windows indicates things could be better… on Linux, unless you work the terminal yourself, e.g. GNU readline’s implementation, input sucks. User types in that scanf prompt, makes a mistake. Backspace… just adds more spam to it, digging them in deeper. Unless you change to “raw mode”, the kernel, not the application, and usually not the terminal either (though it actually kinda can be there, this is not the standard) is doing that input sequence and it is the stupidest possible thing that can work. On Windows, by contrast, when you ask it to just read a line in cooked mode, backspace works, arrow history works (though it is janky, it is there), even tab complete is available in the standard api (though again … not great and fairly rarely used by third party applications, at least they tried).

                                                                                                                              I honestly don’t know why Linux cooked mode doesn’t offer at least something in terms of user experience, since it is all line buffered external to the application anyway. But like I probably would change this too.

                                                                                                                              OUTPUT

                                                                                                                              Outputting data to the linux terminal is just as problematic in theory as input, but in practice it isn’t so bad since most of that is de-facto standardized….. but not all of it. Like the link mentioned here, deciding to add color or not is often done with a isatty() check or a random switch. The sequences themselves are still a state machine that can be corrupted by a program crash or whatever, and the terminal implementation to read them is still a pain.

                                                                                                                              The Windows way of communicating out-of-band metadata brings its own problems. You write text, then in a different function call, change color, then write more text. Bleh.

                                                                                                                              What I’d do is make it take structured commands. This might be length+command+data sequences (which you can imagine they didn’t do in the 300 baud days for bandwidth reasons, but nowadays we’d be generally ok on it) or heck maybe even something like XML just to trigger the haters, but in all seriousness, XML would be quite suitable for the task, given its standardized extensible markup and metadata capabilities, allowing receivers - not just terminals anymore, but any receiver including programs in a pipeline - to strip things they don’t care about. Writing <span color="red">Hello world</span> to either a pipe or a terminal would work since the receiving program can simply strip out that color data. (Of course you could in theory do that with ansi escape sequences too but you’d need to know they are there - which is communicated out of band right now - and the rules for stripping them which is again fairly complex since they come in several forms, but to be fair, parsing XML is not any easier. Anyway my real point here is to put more structure on it, the exact form of that structure isn’t terribly important.)

                                                                                                                              META COMMUNICATION

                                                                                                                              If you want to ask for the size of a terminal, or the current cursor position, or other similar things now as an application, it is a bit of a pain. You need to flush your buffers, write out the request in the same output stream as everything else, then read back - possibly buffering and/or still processing unrelated input that was already in the stream in the mean time - the answer, which comes as some of those escape sequences. If it comes at all…. maybe the recipient doesn’t understand the request or doesn’t care to answer. So you need to work in some kind of timeout, but not too quick or it will mysteriously fail on ssh connections, then when the esc sequence does come and you aren’t expecting it, you’ll perhaps read it as the user hitting other keys. What a mess.

                                                                                                                              If your input and output channels are structured data though, you can work it in here with less trouble. Even piping it into less could take the data and discard it for you, simplifying some application development.

                                                                                                                              Currently, if the terminal wants to know about the application, it might be able to ask the operating system - list open files of your pty or use other extension things. Or maybe the shell will be configured to inform you. But there’s no real hope doing it in-band, since applications wouldn’t expect such a message to come. You could, in theory, send a pseudo key sequence but the other side needs to understand it too, so unless you control the whole stack it won’t work (and now you know why I wrote my own terminal stack lol. ok not really this in particular but it is nice to have the option sometimes). Structured input and output may not necessarily give you an answer - the application can still ignore the request (like odds are the implementation of scanf would ignore anything that isn’t a “give me a line of text” input answer) - but at least you could more confidentially try without worrying about corrupting the stream.

                                                                                                                              I would standardize the terminal getting knowledge about what application is talking to it. Then if it crashes, it can at least reset to the previous state automatically and carry on.

                                                                                                                              UI PARADIGM

                                                                                                                              Most of the above is about the “bottom” end of the system, the implementation of the terminal and communication with it. But I said things suck top to bottom and I meant it. There’s three main kinds of linux terminal programs: full screen interactive ones (e.g. vim, mutt, irc client), interactive shells (bash, python, mysql), and batch processing pipelines (grep, awk). Some are a little bit of both, like less is full screen interactive and tends to be part of a pipeline, or you can run python interactively or part of a pipeline, etc. These generally branch on the value of isatty on either input or output explicitly, thus you might need to either openpty or --color or whatever to override its decision. Applications that fail to do this don’t work very well.

                                                                                                                              Moreover, the very concept of command line arguments gets dicy. touch -- -R; rm * is the classic example - rm doesn’t know if -R is a user-provided switch or a shell-provided filename. Windows, again does this differently - over there, the command line is just a string and the program is responsible for interpreting it. On both systems, pipes need special care and the interpretation of that data gets iffy. On Windows, a pipe might be UTF-8 whereas the console output is UTF-16. How do you know this? Read a couple bytes and guess. lol but not kidding.

                                                                                                                              Neither way is really great, but the Linux way has had pretty good real world success in being both scriptable and usable interactively, with surprisingly nice extensions offered by innovative shells, all the while being fairly easy to add your own programs to it, so we don’t want to throw all that away.

                                                                                                                              And that’s the real problem to making a big change here…. realistically, you’d still have to support the old ways anyway.

                                                                                                                              But if we’re in fantasy land, what I’d love to do is to standardize a number of flags and some of the output. For example, make --help mandatory and define it to output a certain structure so people and machines can read it. Then you can tell what the possible arguments are and what formats they take… then make the interpretation of arguments standardized for the program, so no more rm * confusion. These things together means you can script it in various forms - shell can automatically offer auto-complete by parsing --help in the background. GUI programs could even pop up a dialog box for it automatically!

                                                                                                                              The output, being structured for the terminal already, can be structured for other pipelines too. Metadata like color ignored by pipes while other metadata might be consumed by them. Windows Powershell does this kind of thing, though I think I’d keep some kind of primarily text output - hence my earlier suggestion of XML. XML with tags stripped is plain text again and, if done right, still readable bare in a zero-feature terminal (just like how websites can be easily read by the most basic text browser. right? RIGHT?).

                                                                                                                              The batch pipes and interactive shells can both be used this way. To support pipes or interactive, you can just output <user-interactive-prompt-for-line>Prompt $</user-interactive-prompt-for-line> and then read lines, whether from the prompt or from a pipe. Let the pipes strip the user-interactive part themselves.

                                                                                                                              So I’m trying to embrace higher level the whole way. If you want pipeline batch programs, embrace that and make them explicitly known. If you want fullscreen, that’s similar to what it is now, just easier to program since you don’t need 5000 lines of library code to parse the stream. You could end up a system that still does what Linux terminals do in practice but better.

                                                                                                                              But alas it is all just fantasy anyway.

                                                                                                                              EDIT: I wrote readf when I meant scanf so changed that over (readf is the D language version of scanf but since this isn’t for a D audience I meant to stick to the C names. oops.)

                                                                                                                              1. 3

                                                                                                                                Thanks for the fantastic write up.

                                                                                                                                I would standardize the terminal getting knowledge about what application is talking to it. Then if it crashes, it can at least reset to the previous state automatically and carry on.

                                                                                                                                Note there’s another dragon there, because the terminal supports multiple processes talking to a single terminal concurrently despite having a single global state machine. I think fixing the state issue also implies single terminal ownership. Also, in addition to resetting state on process exit, it should ensure default state on entry; currently child processes inherit the parent’s state, so we have things like processes expecting cooked mode on entry despite a shell process not using that mode.

                                                                                                                                over [on Windows], the command line is just a string and the program is responsible for interpreting it.

                                                                                                                                That’s true, but it’s become a total mess. On Linux, a file name with a space can be parsed by a shell and put in a single argv entry. On Windows, it must be quoted so the child process can parse it. But that means the parent really needs to understand the child’s parsing rules, and the parsing rules are inconsistent.

                                                                                                                                The Windows way of communicating out-of-band metadata brings its own problems. You write text, then in a different function call, change color, then write more text. Bleh.

                                                                                                                                Somewhat meta, but I’d rephrase it and say that the Linux terminal was designed for a VT100 serial line (so everything is in-band) whereas Windows was designed around an RPC model where different message types exist. If you squint a bit, the real difference is ordinary text/input/output being encapsulated in some kind of message structure - this isn’t obvious because Windows doesn’t expose a single stream of data, but it’s the obvious way to turn those function calls into a single stream of data.

                                                                                                                                The big problem in the Windows model is now the terminal emulator is its own process rather than the kernel, you write text (and synchronously context switch to the terminal and back before your program can continue), change color (and synchronously context switch to the terminal and back before your program can continue), write text (and…

                                                                                                                                It’s a shame that the Windows functions weren’t converted into a single stream (on the application side) which would have made SSH type protocols simpler, and eliminated the context switch madness.

                                                                                                                                Input events come as structured data, creatively named an INPUT_RECORD struct…Extensions can now be easily added and applications won’t be lost.

                                                                                                                                In theory, yeah. Except it’s Windows, compatibility is everything, and you don’t know what assumptions some random program made. So what actually happened is console windows became resizable but no new event is generated to indicate that. Instead the existing “buffer size changed” event is overloaded, even though the buffer size isn’t changing, just to poke client apps to know something happened. Back when resizing was via the properties dialog, applications got no notification at all. (I have code that polls to detect resizes.)

                                                                                                                                1. 1

                                                                                                                                  I think fixing the state issue also implies single terminal ownership.

                                                                                                                                  Yeah, or at least put the state per-connection if you do let output be combined.

                                                                                                                                  But that means the parent really needs to understand the child’s parsing rules, and the parsing rules are inconsistent.

                                                                                                                                  Indeed. What I’d actually like with the standardized metadata is that the parent DOES understand the child’s parsing rules at least to some extent, but then it is consistent. Ultimately it would be nice if the argv itself was separated a bit for options vs operands at least (could standardize on the -- thing most things already do).

                                                                                                                              2. 2

                                                                                                                                The interface you have to work with in order to implement a terminal ‘emulator’. The REPL or whatever your ‘shell’ provides doesn’t really factor into it much (more than it blocks possibilities for improvement) though it has evolved around the limitations of the forest of terminal protocols so are in many ways tainted.

                                                                                                                                There are subtle, special semantics for how all the infrastructure is setup to allow your command to talk to your shell to talk to your emulator to talk to this ghastly reanimated corpse of 60ies tech. There are subtle and breaking nuances between behaviours between the different UNIX derivatives. There are functions and interfaces to be used that never or rarely appear elsewhere and talked about hardly ever. Every attempt at a layer has hacks around misbehaviours in what is perceived to be above it and what is perceived to be below it.

                                                                                                                                For just a “fun” one out of many. Take ‘ncurses’ - the popular TUI library. It still has a ‘bandwidth estimator’ that tries to work with the ‘baudrate’ (stty(1)) of your virtual serial port talking to the pseudoterminal device deep down in the kernel to figure out the cost of ‘draw commands’ (cursor to this position, …) so that it can try and buffer just the right amount for the window to be drawn without the cursor stopping half-way through. This estimator needs to know what each draw command translates to and that is dependent on the flavour of terminal protocols available and the quirks of the emulator used, so it checks an environment variable for a terminal emulator name so that it can look those up in a database (termcap(5), terminfo(5)) of the set of hacks to enable/disable.

                                                                                                                                That is for moving the cursor around and writing characters with varying foreground, background and formatting (bold, italic around). There is also signal propagation, flow control, character sets, mouse cursor, clipboard, different screen modes, … There are reasons why xterm is 65+k lines of code and you don’t want to know about any of them.

                                                                                                                                1. 2

                                                                                                                                  There are reasons why xterm is 65+k lines of code and you don’t want to know about any of them.

                                                                                                                                  Well to be fair a lot of this can be simplified if you look at the de-facto standard today. My terminal emulator core is only 5,000 lines of code and my ncurses replacement is 8,800 lines of code (though a good chunk of that is my gnu readline replacement which comes in at about 2,300 lines, but like since cooked getline is so bad a terminal program without something like readline is borderline unusable, hence i integrated it there, and then there’s the Windows implementation and some integrated emulator stuff that pads it out further).

                                                                                                                                  Though I guess xterm speaks X directly too and I put that off in a separate library… which is 20,000 lines but well that does a LOT of things and has bundled bindings and Windows and Mac support too. So it could be much smaller if it was just what the terminal needs.

                                                                                                                                  It is still a lot of messy code on both ends though.

                                                                                                                                  references for my versions: github.com/adamdruppe/arsd terminalemulator.d is the terminal emulator core that does the emulation based on pipes and in-memory (the front-ends are actually in a separate repo here https://github.com/adamdruppe/terminal-emulator but they’re relatively simple since the messy part is in the core lib). terminal.d is my client api. and simpledisplay.d is my window library.

                                                                                                                                  Having done it all though on both sides and high and low level has given me a lot of knowledge that I kinda wish I didn’t have.

                                                                                                                                  But still a de-factor simplification is < 10k lines and still works for 99% of what you’d actually do nowadays, so a fraction of all the things xterm and ncurses have implemented over the years.

                                                                                                                                  1. 2

                                                                                                                                    try and buffer just the right amount for the window to be drawn without the cursor stopping half-way through

                                                                                                                                    Wow. Guess things like that is why ncurses is so well… cursed big and stuff.

                                                                                                                                    Meanwhile good terminals are starting to support sync sequences so we can do things like Kakoune’s smart diff based rendering reliably :)

                                                                                                                                    1. 1

                                                                                                                                      Where is the list of clients implementing it, and what trigger should one use to probe? toggle altscreen is an obvious one, but that wouldn’t be sufficient for tmux to vim – for instance. I experimented with “vsyncing” through XON/XOFF, but as with everything else it just becomes heuristics that break in some or many edge cases.

                                                                                                                                      From that issue: This would indicate the linux console renders every intermediate state instead of what most terminals do: render once there is no more terminal output pending.

                                                                                                                                      Just using pending output to vsync would make find / a very unhappy command (and anything with buffer backpressure really but that one is the obvious test target).

                                                                                                                                      Others go galaxy brain with https://github.com/cipharius/kakoune-arcan – and in return can fullscreen a window to get back to drawing single ‘racing the beam’ buffer with glyph cache shared between all clients using the same typeface, pt size and dpi.

                                                                                                                                      1. 1

                                                                                                                                        list of clients implementing it

                                                                                                                                        I’m not aware of one, only a list of terminal emulators.

                                                                                                                                        what trigger should one use to probe

                                                                                                                                        I’m not sure what this means. I’m not aware of any test cases where sync solved a practical problem (glitch) other than the kakoune one.

                                                                                                                                        1. 2

                                                                                                                                          Wall-of-text warning to avoid assuming background, paragraph 2 and 3 from the end are the meat.

                                                                                                                                          The problems are the same between terminals and other display servers. It’s one of those overarching pesky things in the same vein as ‘colour correct workflow’ - synch is quite hard; almost always the hardest one.

                                                                                                                                          You have a producer working with a command-stream (cursor_to:dx,dy, write:abcdef) (cursor_to:dx2,dy2, write-bold:ghjkl) … and a consumer (server side) which interprets the stream and translates it to the native language of some output, possibly mixes these ‘signals’ together (composition).

                                                                                                                                          If the output imposes a deadline (old printer outputs typically didn’t, just flow control/small-to-no buffers - avoid ‘back pressure’ from a producer sending faster than the chain can handle and you are as good as you can get. With monitors you get binned intervals to fit (vertical/horizontal blank and sync) and then stalls if you miss your timing window.

                                                                                                                                          Terminal protocols adapted, so now you have two different screen modes - the line oriented one and the ‘altscreen’ that works just like a row-resolution tilemap, the tiles just corresponds to glyphs from fonts. As the protocol accumulated more and more features, the processing cost for each of the cells varied and you started to miss the timing window or the command buffers were even larger than what can be processed in one update. Here you get tearing, and you have no other option. It is just less noticeable with a slowly changing signal so user annoyance in terminals is less than other forms of graphics.

                                                                                                                                          Worse still, you also get input to display latency from a typical ‘render loop’ on the producer side as a while(ev = wait_for_input()){process(ev); draw_what_changed(); } format when the ‘draw’ part impose higher costs and block (serial link and all that) while input is accumulated and released in bursts (“embarrassing pause”, “jank”, …) with possibly noticeable variations in timing between the two (jitter) attenuating the effect. This is the problem from the user perspective, it is a QoS one - if you don’t stress or test outside your ‘normal use’ you might not see the problem and cannot properly evaluate the solution.

                                                                                                                                          Not having agency to fix clients, hacks are added to the compositor side to determine if and when it should forward. The “counting characters” trick from ncurses is such a hack, and makes somewhat more sense when you have slow/variable latency connection (so networked). The “double buffer” trick from standard graphics makes more more sense there - but both are hacks.

                                                                                                                                          Other ones were to check which mode the terminal emulator state machine itself is in and guess how many characters you have left to work with; If there is a small burst of data coming you likely have a smaller region update, a larger one - break when you run out of time to the next synch deadline or after about as many character updates as there are cells on the screen. The you need to add a refresh deadline as well because there aren’t always natural synch points in the data stream, find / being a simple example.

                                                                                                                                          So I that is implicit synch and first stage explicit synch – next up is fencing as you ramp up asynchronous processing. You insert command markers to indicate when it is safe to process and forward. The consumer waits for those markers. This is across a privilege boundary, so if you don’t have a timeout you have a denial of service vulnerability as the producer can always “forget” to mark the end.

                                                                                                                                          That is what the protocol change you link suggested. Here comes legacy and feature detection. The producer asks if a mode is set (DECRQM) and gets back something that says ‘zwp_linux_explicit_synchronization_v1’ is in the ‘wl_registry’. Now comes nested composition, which is the default in the terminal stack. The terminal emulator only sees one client in a possibly deep chain or one where the end keep being swapped out. If one producer dies; is killed; shuts down; detached; backgrounded etc. after a (CSI ? 2026 h) the denial of service part kicks in and I see nothing in the suggestion to detect that has happened.

                                                                                                                                          The follow up in heavier system graphics is ongoing now and has been chugging along for close to a decade. Fences aren’t granular enough -> timeline semaphores. Display timing keeps drifting -> cancellation of submitted buffers.

                                                                                                                                    2. 1

                                                                                                                                      But all those predate Linux, no?

                                                                                                                                      Nonetheless, Interesting reply. Thank you. I wonder if there have been attempts at creating a new simpler and more robust ‘wire protocol’ for text terminals.

                                                                                                                                      1. 3

                                                                                                                                        But all those predate Linux, no?

                                                                                                                                        Yes, but there are new generations of Linux users/developers that know of little to nothing else. The author of the link is either one from that group or speaking directly to it. Network effects pushing out diversity.

                                                                                                                                        Thank you. I wonder if there have been attempts at creating a new simpler and more robust ‘wire protocol’ for text terminals.

                                                                                                                                        It’s a 2D problem – you want better solutions for both the vertical (command to shell to desktop) and the horizontal (between commands, cat foo | grep bar). Solving for the horizontal is more intuitive and approachable (typed data exchange), so there are several of those, but you are still bound by a ton of restrictions. Eventually trying to work around those will again add ‘inband signalling’ with desktop interaction mixed in with the data you want to transfer, and anything in the pipes and filters chain can screw it up royally - much akin to what cat /dev/urandom does to your terminal emulator today. That will still not be enough for the ‘resize’ case and sideband signalling gets thrown in again in some form. Say hi to the new boss that looks strangely like the old one but with more JSON.

                                                                                                                                        Solving for the vertical takes you into display server protocols (desktop IPC) with the added twist of special needs for text rendering and grid-of-cells/list of lines. There is even more OS cruft here and even more divergent quirks (hello systemd…). I outlined one possible solution several years ago (The dawn of a new command-line interface) – it has been working for quite a while, I just forgot to tell about it and now don’t really want to.

                                                                                                                                        1. 2

                                                                                                                                          Yes, and it predates Unix as well. When people say “Linux terminal” they just mean “the terminal emulator I am running on my Linux system”.

                                                                                                                                  1. 3

                                                                                                                                    I seem to be the exception in that I found contenteditable actually…. wasn’t that bad. I did a combination of the built in functions via execCommand and some DOM manipulation on the client, then the server did did a html normalization filter before saving, which allowed for pretty legible code and diffs across revisions.

                                                                                                                                    The backspace behavior can certainly get weird, but what I did was have a sidebar that updated the dom position so if backspace wasn’t doing it right, you could just remove a child or strip out a tag on the sidebar. Since there were a number of custom elements in this project, presenting the sidebar as editable dom attributes worked really well for those and the users found it easy enough to apply to other parts too. (That btw is why I went custom. Trying to work that element into the ckeditor or tinymce just proved too much trouble.)

                                                                                                                                    It ended up being… 1800 lines of javascript and then the server-side post-processor about 40 lines. (though that’s cheating a little since it leveraged various library functions I wrote in my dom.d that total to 8000 lines, but still most of it was just loops modifying elements that match various css selectors so i think if it was in javascript it wouldn’t be that much bigger either, aside from the html formatter.)

                                                                                                                                    I wish the company let me open source this. It is very specialized to their needs so not terribly useful applied somewhere else but I was kinda proud of the code.

                                                                                                                                    1. 13

                                                                                                                                      The really interesting thing is that C++ does have a meaningful distinction between POD-types and non-POD-types (Plain Ordinary Data) which affects the semantics of the type quite a lot. But either “struct” or “class” can be used for POD or non-POD. It would have made sense to use struct for POD and class for non-POD but that’s not what the committee chose to do. Instead, you just have to memorize the rules for what makes a POD (it isn’t always immediately obvious, since a single non-POD member variable makes a whole class non-POD).

                                                                                                                                      1. 4

                                                                                                                                        The D language did make a distinction there: struct is more POD (but not exactly because of RAII and similar, but it is value copied on assignment, has no vtable and so on) and class is more Java-style automatic references, virtual methods, etc. People coming from C++ regularly complain about this… it seems they love having both keywords be aliases to each other.

                                                                                                                                        1. 3

                                                                                                                                          The way C# did it was struct is a value type and class is a reference type; both can have functions et al (and prob a vtable as a result), but they do mean something different semantically.

                                                                                                                                          1. 1

                                                                                                                                            Given that there’s a meaningful distinction between POD and non-POD types, it seems to me that it’s good style to use class for non-POD structures. To me, using struct for these is just a way of showing off one’s mastery of C++ arcana, and IMO that kind of showing off has no place in professional programming.

                                                                                                                                          1. 3

                                                                                                                                            What I like about this is the reminder to just think about the in-world light source. I know artists often remind us about that but I never considered it in the context of a ui shadow. Interesting take.

                                                                                                                                            1. 4

                                                                                                                                              This is cool because they are actually exploring the possibilities with existing systems to up the isolation instead of throwing it all out. I’ve done some bits and pieces here - all the techniques they describe are ones I’ve mentioned in various flamewar comments before - but it is really nice to see an actual constructive implementation of the options in one place.

                                                                                                                                              1. 7

                                                                                                                                                A GUI toolkit that is easy as html to use but as memory efficient as native.

                                                                                                                                                1. 5

                                                                                                                                                  For some reason I’m reminded of XUL. And I think I just heard a Firefox developer cry out in terror.

                                                                                                                                                  1. 2

                                                                                                                                                    the big question there would be what features do you consider essential from html?

                                                                                                                                                    1. 2

                                                                                                                                                      This is an idea I’ve been toying with for some time. Basically an HTML rendering engine meant for GUIs, like Sciter. But instead of Javascript, you’d control everything using the host language (probably Rust). If you’d want JS you’d have to somehow bind that to Rust.

                                                                                                                                                      I think this could really work out. However: I’ve dealt with XML and HTML parsers for years in the past, and I’m not sure I’m ready yet to dive into the mess that is HTML again.