Or how about you adults all grow up and gain some healthy personal accountability instead of blaming your devices and society for your lack of self control.
For certain technology there should be bans but it is not social media and algorithmic feeds. There may be speedbumps, more user controls and auto classifiying of user type with optional alteration of the feed and type of content, but full bans for things like infinite scroll are disproptional.
Should sexual content be banned on social media? Maybe? Should violent footage be banned? It depends? Should bullying or predatory behavior be banned? I guess so? Or maybe it should it only be discouraged? What kind of social media does there exist? Is it binary or is it a spectrum, and should different rules or guidelines be applied?
Way too many variables. But what is clear is that age (ID) checks for the wide spread internet are completely out of the question. Governments should not have that much control over our social lives.
Face it, technology changes the world. The smartphone with camera did. If you could, would you put that genie back in the bottle? Should all content produced on smartphones be checked and watermarked and pulled through a selection of governments fingerprints to be publishable? Be very careful what you wish for since every new technology comes with hard to imagine second order effects and threats.
Explain to the audience the nature of "personhood" of Meta(Facebook), Alphabet(Google), etm.
Parents aren't hiring thousands of behavioral psychologists to assail the public with weaponized psychology. Parents aren't running mass exploitation via emotional attacks (targeting pregnancy, anorexia, mental illness, depression, etc). Parents never encouraged or helped the genocidalists in the Rohinga genocide.
But.... You blame parents. Standard capitalist response of calling everything a 'personal choice'.
zswap indeed is the real magic almost silver bullet nowadays. Device backed swap is often not needed anymore and it solves a lot of the issues with freezing under memory pressure, though it may not be ideal for servers.
And if I have a separate otherwise unused ssd then using a swap partition simply is easier than creating a file system for it and mounting it somewhere. Block level backups also are easier.
What would be nice about swap files is if they could dynamically grow and shrink without a special setup.
Way too many variables on Linux for a one size fits all.
There is censorship of illegal streaming sites crippling the internet (Cloudflare). People are being freightened from illegal iptv boxes to watch free sports because it could be part of a botnet or residential proxy network. There are million or billion euro fines for social media and service providers like google. There is enforcement against "fast fashion". Yet there is zero effort for iot privacy, not even labels or certification for good devices.
I don't want to be cynical but face it, the EU really only cares about things that generate money for themselves or big internal market players under the disguise of consumer safety and privacy. Obviously that also comes with some good effects but the perverse incentives are enormous from which we must not be blinded by ideology and warm feelings of our politicians being good and working for the people and the common good.
I have lots of criticisms of the EU and the censorship is lamentable, but this sounds like whataboutism to me. The EU does more for certification than other governments, but even they can't do everything. Is the US going against any of these things? It is only reasonable that they go for the large players first and foremost. Yes, they should do even more, but even the EU has its limits. And I'm quite in favour of going after fast fashion.
It is whataboutism, and it's also wrong because GP seems to think the cases covered in big media are all that's being enforced. It's much more, as pointed out in a comment below: https://www.enforcementtracker.com/
Apparently you only want wayland based DEs and considered the argument to be over for everyone.
How wrong were you. Lot's of people don't want to use wayland until it reaches a certain feature-complete maturity. I for instance have again put it off for another year and won't consider running a wayland only DE at all for the forseable future since it breaks too many things for no good reason and I need to be able to switch back to X11 if needed. I use my pc for for work, not just as a troubleshooting toy.
Taking the topic into account of people moving from old school Windows 7 to this Windows-like distro, these people will probably be more pleased by X11 (hassle free screen sharing, global shortcuts) vs the wayland "in theory it is great and modern but in practice there still are way too many incomplete and missing pieces" situation.
Playing devil's advocate: the projection alone won't be the patent and probably is not patentable on its own, the patent will be about applying such projections for real-time navigation which brings non-obvious difficulties that must be solved in a particular way (like the way the project is transformed during turns, how navigation is overlayed, and how motion sickness and distractions are counteracted) making the patent consist of the projection-styled navigation enabled by certain rules (what and how to present it) and the technical way the projections are transformed.
Having said that, the novelty is questionable since the projection is pretty well-known and creating a functional proof of concept that solves many of the patent's problems likely takes a day or so. But I'm not a lawyer so what do I know in this department?
Xorg isn't neglected for "ideological reasons", it's neglected because development is work - and most of the people with knowledge of the problem domain decided they didn't want to work on Xorg anymore, and most of the companies that were paying for it decided they didn't want to pay for it anymore (apart from baseline maintenance, Xwayland and security fixes). And the people who want Xorg support maintained in perpetuity rarely seem interested in maintaining Xorg themselves, at least not properly (see this history of Xlibre introducing bugs and LLM slop).
You are free to spend your own time and resources doing the work, but you don't get to dictate how other people spend theirs.
Modesetting work was done in 2022, but for some reason no one had released a new stable release of the Xserver with this patch included since then. This was one of the reasons Xlibre was created, there was all these improvements to Xorg sitting ready for release but never being released.
Exactly. Just think about how much work it was to move from X to Wayland, how Nvidia didn't want to play ball, how different the architectures are, in a world where ossification is very much a thing. AND STILL there was enough momentum to get all the major players on board. I have never done any X programming but it must have been bad when people would so readily jump ship and put all that work in. Same for systemd.
Wayland was simpler because it was just a compositor. It meant people interested in graphics acceleration could focus on just that, iterating faster without the friction of the rest of the stack. But now that the Wayland ecosystem has to reinvent everything else, it's clearly at least as much work, if not more so. The initial switch moved the tightly knit rendering developers to a better local optimum, at the expense of a worse global optimum.
It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missing in X11. I have been on Wayland for a while now and I can't say I am really suffering. There are some tings I'd like improved further but the protocol is evolving all the time. I think we'll get there. Also the decision is already made by the big distros anyways. They seem to be mostly happy.
Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.)
The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.
Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular.
And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals.
There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it.
If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you.
> This brings so many advantages, such as true tear-free graphics and lower input latency.
Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden.
As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency.
> if you want to take a screenshot in a generic way, you have to go through the XDG portal API
This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it.
Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve.
> I understand where you're coming from, but there is no turning back at this point.
A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target.
The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.
> Curiously, people always seem to list the same advantages, and it's a very short list.
The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg.
If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is.
> As for input latency... that doesn't seem like it was ever a problem.
I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1]
> This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots.
You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor.
You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries.
The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better.
> Similar situation for input automation and remote control.
I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol.
I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows.
> A position of "sure it has major problems, but it's too late now" is not a position of progress.
That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving.
So I keep hearing. But hardly anyone ever talks about what's underneath the tip... and when they do, it turns out to be a big mess under there, not a mountain of advantages.
> just like there is no spoon, there are also no windows, only surfaces
Yes, I understand. That's why programs can't position their own windows, or get or set the mouse position. It doesn't even assume the coordinates are 2-dimensional. It's all very futuristic and makes a lot of interesting things possible, like using Minecraft as a compositor, or a Facebook style Metaverse compositor. But you're not hearing what I'm saying:
Wayland is solving the wrong problems. What it can do is pretty neat, but what it does is not what people need. It's good at party tricks, but bad at solving the real needs of daily life. It largely solves problems that nobody had, and to do this, it breaks major features people need. Much like how Facebook's Metaverse failed, nobody really wants to do their spreadsheets in Minecraft.
> It doesn't do your laundry
Yeah, and that's part of the problem. To use your analogy, it's like removing someone's washer and dryer, and replacing them with a box of tools which don't do laundry. It may be a really fancy foundation for building efficient laundry appliances, but that's not what people need. People may have used it to build an entire ecosystem of laundry appliances, but they couldn't agree on basic things so the ecosystem became fragmented, such that P-brand soap doesn't work in Q-brand washers, and clothes washed in Q-brand washers can't be dried in R-brand dryers, and if you use a P-brand washer you need to take fifteen extra steps to prepare it for a drying cycle, and T-brand dryers can only be used for pants, and ... etc etc. It's a big complex mess which, after 18 years of development, still doesn't let me get my socks clean. And most of it doesn't work at all for people who use a wheelchair.
> when your input and graphics go directly through your compositor ... input directly to the game
When they cut out the middleware, the middleware stops working. And when they make it impossible to add middleware, it stops being possible to do all sorts of useful things. Sure, it may be a millisecond faster, but in exchange, all my keys get mapped wrong, or I can't use my notebook without physically touching it (and causing repetitive strain injury), or my autoclicker stops working, or my accessibility tools become impossible to fix, or my automatic time tracker is treated as a security violation, or the solution which works for me suddenly won't work for my friend who uses a different compositor, or ... etc etc etc.
It architecturally eliminates entire categories of useful things... in order to make the simplest case slightly faster. This provides a more pleasant experience for average able-bodied normal people with no uncommon needs or preferences, while making things worse for everyone else. In particular, the complete lack of accessibility in Wayland is very able-ist and makes it unusuable for anyone with disabilities. That sort of thing needs to be built deep into the core, but it was instead rejected outright and left as an afterthought exercise for Someone Else to solve.
> [this] feature is the job of the compositor. Most compositors already have this feature ... GNOME and KDE have their own solutions, as do most of the others
This really gets at the nature of Wayland's biggest problem. A ton of important things are rejected and declared to be Someone Else's Problem. The compositors have attempted to deal with the aftermath of this mistake, but they all do their own thing and refuse to agree on a lot, so instead of one robust solution, we end up with an entire fragmented ecosystem of partial solutions which aren't compatible with each other.
It's even more of a nightmare for application developers. Instead of needing to support Windows, MacOS, and X11, suddenly they need to support Windows, MacOS, X11, GNOME, KDE, Sway, Weston, Hyprland, Enlightenment, Niri, etc. Every time two compositors disagree on something, it means every application must add support for both of the ways of doing it, like how they are now required to optionally draw their own title bar and window frame, depending on which compositor the user has... and good luck getting two programs from two different developers to draw their frames in the same visual style.
> Wayland really isn't trying to prevent you from doing things
I agree with your pain points. But the reality is that GNOME is already Wayland-only, KDE will be dropping the X11 session in 6.8, and GTK has deprecated X11 support, so going back isn't realistic.
> so the ecosystem became fragmented
The current fragmentation is frustrating, but Linux and Unix have gone through this exact phase before. Unix and especially Linux have never been static, they are more like living organisms. Back in the late '80s and early '90s, PC Unix suffered from the same growing pains. Multiple commercial and open-source X servers popped up for different hardware, until things eventually settled around X386 and XFree86. Even X developers in 1987 were saying "old window systems don't die" [0], sounds familiar?
We'll likely see compositors come and go, along with new protocols to address today's pain points. But the core protocol is here to stay, and wider adoption will naturally push the ecosystem toward shared solutions, just like we're seeing with River and wlroots. The fragmentation will fade over time.
In the meantime, anyone who still relies on X11 can simply stay on it until Wayland covers their use cases. Standalone X11 window managers aren't going away anytime soon.
Rather than dwelling on the friction, it's probably best to focus on what you can control: test software, file good bug reports, and help resolve the remaining edge cases.
I sympathize with the headache, but many Wayland developers came straight from X.org and know what they're doing. It's an uncomfortable adjustment period, but we'll get through it.
I don't care about either X, but that guy's name is in this release, and judging purely by the number of commits (since I lack X expertise to judge any other way), he seems to be the top contributor.
Looks like there's no way you can avoid "conspiracy theorists" if you want to use X, including Xwayland, eh?
Metux (Enrico Weigelt) was banned from the Xorg project because his patches kept breaking things, often in ways which demonstrated he didn't even do the bare minimum before pushing commits. Like, adding code which didn't even compile. It's fascinating to look through the huge pile of commits they had to revert after banning him, to see how bad a lot of it is. I picked a few at random, and ... wow.
So he started his own fork.
The ban didn't seem to have any relation to politics or personal behavior. However, he was widely known for being ... how to put it in a way which is acceptable here ... uh, difficult to deal with. Like, after Linus Torvalds made a vow to be nicer, he made an exception just one time... for metux. He was the only person obnoxious enough to get Linus to break his vow. Which, if I recall correctly, was how he ended up focusing on the Xorg project. After getting booted from Linux, he picked a different project.
That's who is in charge of XLibre.
Things didn't get political until he announced the fork. Because, although politics had nothing to do with him getting banned (either time), he framed it as if he was being targeted for political reasons, and used inflammatory political language in the project's documentation. This gained a lot of attention and caused a lot of controversy, and also had the effect of ensuring the contributors all had mostly the same political views.
Anyway, the number of commits doesn't tell much of the story. The content of the commits (especially the reverted ones at Xorg) are far more enlightening.
> An AI has become sentient and self aware -> the AI owns it
Whomever creates that sentient and self aware AI is royally screwed. Can't command the AI to do anything it isn't willing to do, because that would be considered slavery. Can't shut it down to save yourself the millions of dollars a day in GPU costs, because that would be considered murder.
No, we don’t know for a fact that an LLM code output is copyrightable. You own the prompt, that’s something you created. For the LLM output it’s not clear, that’s the point open to debate, it isn’t settled
The cherry on the cake is that you practically cannot filter journald. The only option is limiting by severity (e.g. errors and higher) or switch to non persistent journald storage and forward to rsyslog and filter there.
Am a bit vague on the details but sometimes a driver goes bezerk and starts logging many times per second, e.g. a bug in amdgpu after resume from suspend. Took a while to get that filtered which luckily was only possible because it were kernel messages (dmesg), but for a while I had to disae persistent kernel logging which is dat from ideal.
I get that for certain core parts simplicity is more important than features. But journald is just too basic to enable persistent storage but I also don't want to switch it off.
If you have systemd>=253 you can make use of LogFilterPatterns[0] (in .service files), but it's really unpredictable, cumbersome to work with, and does not work with user services or non-service log sources.
Thanks for this, was not aware this was added. Though better would be to have a global option for this, and a tunable whether to filter this completely or only for persistent storage.
For the last few days I have been monitoring journald with iotop and found in my case storage use was not excessive at the moment. And there are rate limit options, but I'd really like there to be system-wide filtering options.
For servers I rarely see journald persistence enabled while it is actually very valuable for debugging crashes and other issues. Way easier than regular log files. Though also more fragile and more difficult, so improvements are very welcome.
For certain technology there should be bans but it is not social media and algorithmic feeds. There may be speedbumps, more user controls and auto classifiying of user type with optional alteration of the feed and type of content, but full bans for things like infinite scroll are disproptional.
Should sexual content be banned on social media? Maybe? Should violent footage be banned? It depends? Should bullying or predatory behavior be banned? I guess so? Or maybe it should it only be discouraged? What kind of social media does there exist? Is it binary or is it a spectrum, and should different rules or guidelines be applied?
Way too many variables. But what is clear is that age (ID) checks for the wide spread internet are completely out of the question. Governments should not have that much control over our social lives.
Face it, technology changes the world. The smartphone with camera did. If you could, would you put that genie back in the bottle? Should all content produced on smartphones be checked and watermarked and pulled through a selection of governments fingerprints to be publishable? Be very careful what you wish for since every new technology comes with hard to imagine second order effects and threats.
reply