This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
> This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
>
> Wayland has conflated those two concepts by making every Wayland compositor have to do both roles.
This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).
X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.
> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.
Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.
I'm going to partially agree and partially disagree, I think...
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.
> [...] I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm.
I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.
Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.
> You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.
Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.
The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.
From an outsider point of view it looks like the ecosystem would have been much healthier if KDE and Gnome had used wlroots. Get everyone talking in the abstraction so plugins can be written.
Whereas Wayland originated in 2008, sway didn't exist until 2015, Wlroots 2017. This is not when they were ready merely when development begun.
Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.
Have you looked into it? I believe writing a wlroots compositor to be in the general ballpark of as difficult as writing an Xorg window manager—which is, beyond the type of project I’m likely to take up in my spare time, but at least doable by mere mortals.
Far more work. I wrote the X wm I'm currently using in a couple of weeks and it's a few hundred lines of code. You can get a working X WM in a few dozen lines or tens of thousands. Mine is ca. 700 at this point (floating+tiling).
I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
Yes, the lack of an unified server is such a shame. The great selling point of Wayland originally was that it avoided extra context switches by unifying the server and the window manager, this means every window manager must reimplement the server and every protocol by itself. But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.
Ecosystem effects mean that it kind of is. Even if we made the software in question (probably on top of wlroots, maybe even just extending wayfire which IIRC kind of already has the plugin system you need?) there is zero chance GNOME or KDE will use it, and I wouldn't bet even on sway or such.
On the one hand, yes, I'm tempted to just ignore GNOME+KDE because they'll never play nice, and just go build something better without them.
On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.
The overhead is low enough that my current wm is written in Ruby and the WM is nowhere near the hot path for anything. The notion that it's a problem or have the WM put of process is nonsense. If I ever write a Wayland compositor, I'll add an out of process WM interface, because it's far nicer to be able to restart at will without killing apps.
> If I ever write a Wayland compositor, I'll add an out of process WM interface
This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?
I think the main thing stopping it is that people get "stuck" on the compositor since even writing a wlroots based compositor is far more effort than the bare minimum for an X wm.
I accidentally did that with the original Team Fortress on Quake, and the Mechwarrior 2: Mercenaries CD. I always felt like the track from that CD that went with the `rock` map was a good match, but I couldn't really say why.
I haven’t used it recently but I believe it sets a header on the request when it comes from HTMX so you can change whether you send the whole page or just the fragment back.
You can also just send the whole page and use other features to select just the part that you want to update (obviously that has a cost of sending the whole page though).
My siblings and I would tape a monopoly board to the TV to split it vertically and then play team games to get around “screen cheating”. I think it had the best of both worlds. We were still in the same room but we could ambush and sneak up on each other. Definitely less expensive than this solution.
Goldeneye 64 was the best bang for our buck of any game we ever bought. We did the same thing with Perfect Dark.
Thanks. My problem with Monopoly is that I always feel like about 10 or 15 minutes into the game it is clear who the winner will be, and then the next two hours are a slow grind in which everybody else slowly becomes dust.
That is the point of this game : "It was intended as an educational tool to illustrate the negative aspects of concentrating land in private monopolies."
My friends and I played a version of monopoly where every unowned property that is landed on goes up for general auction among all players. To speed up the process of auctioning all players write their bid down and then it is shown all at once. This reduces the luck of the game somewhat in regards to luck in being the first to land on a property tile, and adds a skill of being able to figure out what a property is worth in the context of the board situation. Every x-mas I try and usually fail to get my family to play it with me.
The rules of monopoly are that if you land on an unowned tile you must buy it. If you decide not to, or can’t afford to, it can be bid on. Highest bid gets it. Even if it’s less than the cost.
The sibling mentions about the intentional aspect of this, but the other factor is the popular house rules around free parking and not auctioning properties, both of which contribute to there being far too much cash in the game. This is part of why it takes so long to go bankrupt.
My friends and I invented the 'Joint Venture' ruleset precisely because of this reason. Under these rules, you don't need to own a monopoly to start building on it. Instead you can form an agreement with the other owners, a JV so to say, and then you can pool money and start building. Income from the properties can be split up between the JV partners in any manner of their choosing.
But since the rules of the game only allow you to build if you have a monopoly, when a JV is formed, all owners should nominate one person and transfer their properties (within that monopoly) to that person, who then becomes the owner of the monopoly and can do with it as he wishes.
This leads to a lot of fun situations when there is conflict between the JV parties about the usage, or if the owner requires money for financing something else, and decides to 'backstab' the JV partners. Keeps the game entertaining for hours!
I've been playing a LOT of monopoly online recently and I agree with you - whoever gets the first monopoly on the second or third side of the board is going to win 90% of the time. And if you're playing with an inexperienced person who doesn't realize the value of never, ever giving another player a monopoly, then whoever bamboozles them first is likely to win.
I would usually forfeit and leave whenever I wasn't first, and generally speaking so did anyone else.
My 9yo loves numbers. When most people play Monopoly and act as the banker, they have the board in front of them and the bank's funds to the side. When he plays, he has the bank's notes laid out in front of him and the game's board is an afterthought off to the side. Thankfully I don't think he is the cheating sort, yet.
hmmm I feel the opposite. The absurd amounts of money a person can lose by just landing on two build houses of their opponent means that even someone who is winning can suddenly start to lose within a few turns.
Halo worked well as the pistol (starting weapon) is all you really need. So there’s no massive disadvantage on spawn.
I remember playing online 2v2 (halo on xbox, there was no online so it was actually system link, lan, run over the network. Bloody hard work from Australia) in which screen cheating is most definitely a feature.
Nothing more bonding for two brothers to duke it out 1v1, and then discover you’re leagues ahead of everyone online in 2v2.
As I recall the Xbox had an Ethernet port and Halo supported up to four consoles. I think there were some limitations. Not sure if two teams of 8 were possible but I think 4x4 was. At a minimum I believe dedicated screens were possible in a four player game.
The PS2 had something similar (only two consoles) but it used Firewire because Sony is the Apple of Japan.
I didn't know 4v4v4v4 was possible,
we mostly did 8v8 CTFs.
I gave up on PS2 games because the first few I tried would say 2 or 4 or more players and too many times they meant "1 per PS2" without disclosing that ahead of time where xbox and GC reliably had splitscreen on pretty much any multiplayer game.
I’m honestly not sure 4v4v4v4 was a thing but I have a memory of doing four way team death match. I could be making things up. That was a long time ago.
During undergrad in the US we used to use Xbox connect. It would function had a lan bridge to other people so you'd just use the regular halo UI to find a game.
So it has no real online features but they were grafed on by a bunch of tricks.
Ah Xbox connect. Had mine and my brother's xbox on the same switch so we could play together with others.
We used to connect across the Atlantic to a host in the US, dude had a fat fibre pipe so 16 player Halo 2 with 0 lag and modded features (like spawning a warthog for each player in blood gulch for Cat vs. Mouse games.)
Fun times. Halo 3 iirc made some changes to the netstack to break it though :(
Yeah that's how my group of friends came to see it. It was just another skill we could compete with. Some of us could watch the other three screens most of the time and hardly look at our own, which led to strategies of running around while staring at floors and walls to mask our position better.
The game has a lot of tricks too as I recall. Grenade launcher grenades only explode when hitting the ground, not other surfaces, so if you know what you're doing you can kill someone half way across The Complex with one. Oh, and some guns can shoot through doors, but the door must be open(ing) for it to actually register the hit, otherwise it is just rendering a tracer. Stuff like that.
Perhaps someday I will have an opportunity to save the world with my license-to-kill, postols-only, Complex skills. Only then will my misspent youth make sense.
I remember having a good hiding spot near the ammo for the FarSight and just taking out my friends on repeat for like 20 solid minutes before they managed to get to me and kill me. Totally OP in wrong hands and amazingly fun.
One of my honest bigger complaints about newer first person shooters is that they round all that corners off the map. There's no good sniper nests.
In Halo Infinite anywhere you could reasonably snipe from is out of bounds. They give you a grappling hook, but don't let you go anywhere interesting with it in the multiplayer.
I loved Perfect Dark but never completed the game as my system would always freeze due to the number of explosions during the last level’s boss battle. Even with the expansion memory pack thing.
I was an unashamed screen-looker in the Goldeneye days, and got no end to the raft of shit I got from my friends over it.
As luck would have it, those skills were a great advantage when playing games like Halo LAN parties where I was sharing the screen with my allies rather than enemies. A quick glance and I could gauge their location, situation, and how best to help them out.
Once I discovered `lib.fakeSha256`, I just put that in the derivation, try to build it and then use the error message to find the correct hash to put into it. Probably not the fastest way to do it, but it's easier for me to remember.
Your third point about having to encode everything isn’t quite true. Your example is just brittle in that it doesn’t allow additional values to show up causing it to break when they do. That’s not a feature of static type systems but how you wrote the code.
This blog post[1] has a good explanation about it, if you can forgive the occasional snarkyness that the author employs.
In a dynamic system you’re still encoding the type of the data, just less explicitly than you would in a static system and without all the aid the compiler would give you to make sure you do it right.
It's important to note that this article talks about something that is missing from most statically typed languages.
It's best to refrain from debating static VS dynamic as generic stereotype and catch all.
You need to look at Clojure vs X, where if X is Haskell, Java, Kotlin and C#, what the article talks about doesn't apply and Clojure has the edge. If it's OCaml or F# than they in some scenarios don't suffer from that issue like the others and equal Clojure. But then there are other aspects to consider if your were to do a full comparison.
In that way, one needs to understand the full scope of Clojure's trade offs as a whole. It was not made "dynamic" for fun.
Overall, most programming languages are quite well balanced with regards to each other and their trade-offs. What matters more is which one fits your playing style best.
I think many peoples' experience is that most real world data models aren't as perfect as making up toy examples in blog posts. Requirements and individuals change over time. You can make an argument that in a perfect world with infinite time and money that static typing may be better because you can always model things precisely, but whether you can do that practically over longer periods of time should be a debatable question.
I've seen this article and I applaud it for addressing the issue thoroughly but I still am not convinced that static typing as we know it is as flexible and generic as dynamic typing. Let's go at this from an other angle, with a thought experiment. I hope you won't find it sarcastic or patronizing, just trying to draw an analogy here.
So, in statically typed languages, it is not idiomatic to pass around heterogeneous dynamic maps, at least in application code, like it is in Ruby/Clojure/etc. But one analogy we can draw which could drive some intuition for static typing enthusiasts is to forget about objects and consider lists. It is perfectly familiar to Scala/Java/C# programmers to pass around Lists, even though they're highly dynamic. So now think about what programming would be like if we didn't have dynamic lists, and instead whenever you wanted to build a collection, you had to go through the same rigamarole that you have to when defining a new User/Record/Tags object.
So instead of being able to use fully general `List` objects, when you want to create a list, that will be its own custom type. So instead of
val list = List(1,2,3,4)
you'll have to do:
case class List4(_0: Int, _1: Int, _2: Int, _3: Int)
val list = List4(1,2,3,4)
This represents what we're trying to do much more accurately and type-safely than with dynamic Lists, but what is the cost? We can't append to the list, we can't `.map(...)` the list, we can't take the sum of the list. Well, actually we can!
So what's the problem? I've shown that the statically defined list is can handle the cases that I initially thought were missing. In fact, for any such operation you are missing from the dynamic list implementation, I can come up with a static version which will be much more type safe and more explicit on what it expects and what it returns.
I think it's obvious what is missing, it's that all this code is way too specific, you can't reuse any code from List4 in List5, and just a whole host of other problems. Well, this is pretty much exactly the same kinds of problems that you run into with static typing when you're applying it to domain objects like User/Record/Car. It's just that we're very used to these limitations, so it never really occurs to us what kind of cost we're paying for the guarantees we're getting.
That's not to say dynamic typing is right and static typing is wrong, but I do think that there really are significant costs to static typing and people don't think about it.
I’m not sure I follow your analogy. I think the dynamism of a list is separate from the type system. I can say I have a list of integers but that doesn’t limit its size.
I can think of instances where that might be useful and I think there’s even work being done in that direction in things like Idris that I really know very little about.
There are trade offs in everything. I’m definitely a fan of dynamic type systems especially things like Lisp and Smalltalk where I can interact with the running system as I go, and not having to specify types up front helps with that. Type inference will get you close to that in a more static system, but it can only do so much.
The value I see in static type systems comes from being able to rely on the tooling to help me reason about what I’m trying to build, especially as it gets larger. I think of this as being something like what Doug Englebert was pointing at when he talked about augmented intelligence.
I use Python at work and while there are tools that can do some pretty decent static analysis of it, I find myself longing for something like Rust more and more.
Another example I would point to beyond the blog post I previously mentioned is Rust’s serde library. It totally allows you to round trip data while only specifiying the parts you care about. I don’t think static type systems are as static as most like to think. It’s more about knowns and unknowns and being explicit about them.
I believe your comments provided a good insight into your approach to programming. I may be wrong in my understanding, but let me elaborate.
You expect your programming language to be a continuation of your thoughts, it should be flexible and ductile to your improvisations. You see static typing as a cumbersome restricting bureaucracy you have to obey to.
Whereas I see type system like a tool that helps to structure my thoughts, define the rules and interfaces between construction blocks of my program. It is a scaffolding for a growing body of code. I found that in many cases, well defined data structures and declarations of functions are enough to clearly describe how some piece of code is meant to work.
It seems we developed different preferred ways of writing code, maybe, influenced by our primary languages, features of character, type of software we create. I used Scala for several years, but recently I regularly use Python. Shaping my code with dataclasses and empty functions is my preferred way to begin.
It is absolutely possible to have the same type for values that have the same shape.
You can have a `Map k v` that is a record that dynamic languages have that they call object/map.(make k/v Object or Dynamic if you want)
You don't need to create a new type with precise information if you just want that(no you don't need to instantiate type params everywhere). There is definitely limitations in type-systems (requiring advanced acrobatics) but most programs don't run into them and HM type system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...) has stood the test of time.
I’ve used Input Sans[1] with Python in the past and it works pretty well except if you use white space for formatting or ascii art as opposed to just indenting.
It works because the spaces are nice and wide unlike in a typical proportional font.
I don’t use it anymore mostly because I wanted something with a little more character but it’s worth a try.
Does anyone know the US case law on the 1st amendment being applied to corporate actors?
I see the argument often that things like this are a free speech violation but the 1st amendment says “Congress shall pass no law...”. It doesn’t apply to actors other than the state.
I’m not defending Google’s actions here but I also don’t think it’s technically a free speech violation at least as the amendment is written, so I’m wondering if there are any cases addressing this sort of censorship w.r.t. the 1sr amendment.
There's the first amendment and there's the concept of free speech. This absolutely violates free speech but does not violate the first amendment.
The only current framework to protect freedom of speech from private companies is to designate them as common carriers, e.g. phone companies legally cannot police what is said over their wires.
I don't think it's necessarily anti-free-speech. The idea of free speech is that everyone should be able to express their opinions without being prosecuted for it, not that everyone is entitled to a platform for those opinions. You should be able to write an article about absolutely anything, but you're not entitled to put it in my newspaper.
I of course agree that the mastodon ban is a bad move because it sets a double standard where browsers can access arbitrary web content but other apps can't, and because it grossly limits the things that the average user can do with their device. However, these are consumer rights issues, not free speech issues.
I think what a lot commenters are saying is that within their conception of the bigger idea of free speech they do consider themselves entitled to have their thoughts distributed by established platforms. Or put more mildly, platforms like Google ought not ban people for their content because it's the right thing to do. But I don't see many people advocating for government intervention, not with specifics anyway.
I think that's kind of a strange take. Like, if you are entitled to put an article in my newspaper no matter what the article says, doesn't that unduly restrict my speech by forcing me to endorse your ideas by using my platform to distribute them?
If Google doesn't want to distribute your ideas, I think it's odd to say that that's wrong of them. I do think that it's a problem that they get to act as a gatekeeper like that in the first place. I think the solution is to break up larger platforms and create a diverse ecosystem of smaller options, not to forbid platforms from ever moderating their content.
The tools exist with which to do it. People have reverse-engineered the reMarkable enough to start creating Rust libraries to support the hardware[1].
I've been thinking of experimenting with building a Sketchpad-like system on it. With Rust, you have access to LLVM fairly easily, so you could probably do something with JIT compiling code (maybe a Smalltalk dialect) to give whatever you build a programmable interface.
Why Smalltalk? It's simple syntax would be easier to deal with on the reMarkable, and you might be able to look at doing handwriting recognition to let you write the code with the stylus. Could also go with a Lisp, for similar reasons.
All of this is just speculation because I haven't started it for lack of time, but I'm really interested in exploring what's possible in that space. The system specs will probably be constraining (I haven't looked at them recently) but I'm sure they're far far more than what Sketchpad had.
I've been eyeing the Remarkable up for some time now. This lib looks pretty cool. Anyone here using this device that could share opinions on its quality and utility?
I came to it from the perspective of wanting a digital notebook that I could also load PDFs on and write margin notes in. I used to keep handwritten notes in notebooks, mostly bullet journal style, and I've completely converted over to using the reMarkable for that.
For that purpose, it is excellent. The software has a few bugs that I've bumped into from time to time, but nothing show stopping. The feel of the stylus on the screen is much closer to pen and paper than anything else I've tried.
It's running Linux and you can shell into it when it's connected to a computer via USB (it appears as a network device on the host), so even if the company collapses, it's very hackable as evidenced by the library I mentioned above.
That said, the price point is a bit high for what it does, and the first thing I always get asked about it is whether it converts my writing to text, which it doesn't.
My wife is in grad school and used to print out papers she needed to read for class so she could write margin notes, and now she just loads the PDFs on her reMarkable and keeps notes there.
The EPUB support was dodgy last time I tried it. The one book I loaded on it would only show one line per page until I adjusted the font size. I generally prefer PDF format anyway, since it's usually laid out better and I'm usually reading technical books on it anyway.
All that said, I highly recommend it, if it's something you think you'd find useful, and aren't put off by the price tag.
This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.