spystath

For every couple "just works" cases there is a corresponding "doesn't work at all". Given the diversity of the PC as a hardware platform there are going to be edge cases. There is no avoiding that. I'm fairly certain there are cases where hardware "just works" on Linux but doesn't do so on Windows either because there is no driver any more, or because the driver is borked, or any other reason. And here's my anecdote: the wifi on a windows laptop I had once kept dying or dropping packets randomly. Turned out the shitty Killer wifi driver was doing some kind of "optimisation" <insert hand-waving here> to improve throughput. It took a lot of google-fu to find out what the problem was. And this is where I believe you are wrong wrt the command line. The command line is a powerful diagnostic tool and having text files as configuration is much more accessible than delving into a 13-level deep registry chain.

Now, I'm not claiming that everything is smooth sailing on Linux, because it isn't, but the "I've spend hours trying to debug something" argument can be said for both sides and if it comes to that the mythical "average user" won't be able to sort it out by themselves in either case, command line or not.

In reality the Linux and web versions are not similar to the actual Windows client. For instance the Linux version is stuck to 2×2 video streams at best, doesn't support background blurring, audio/video quality is inferior, doesn't support sharing a single window, no breakout rooms etc [0]. None of these are of any considerable importance to me but Linux or the web has never been priority for Teams nor will ever be. In fact I will not be surprised if/when Linux is dropped completely when transitioning to Webview2. Judging by the "PR-speak" [1] this is what probably will happen anyway.

[0] https://microsoftteams.uservoice.com/forums/555103-public/su...

[1] https://github.com/MicrosoftEdge/WebView2Feedback/issues/645...

On some linux distributions [0] microcode is loaded early during kernel boot. So it's a matter of pinning the package to a previous version. No idea what happens with BIOS/UEFI updates though, although you can roll these back too. Obviously the "proper" way here is to have open source microcode but I can't see that happening anytime soon.

[0] https://wiki.archlinux.org/title/Microcode#Early_loading

This might be me being pessimistic but there are no web standards any more. It's Chrome standards. You can fall in line or drift into obsolescence. We never really got rid of the IE dominance on the web, we merely exchanged one boss for another. I get it it's not _quite_ the same since we don't have the ActiveX nonsense any more but it certainly feels like we're living in Google's vision of the web. Monocultures are harmful but that's we get to live with.

The problem with proprietary chat services is that if, for instance, Discord pulls a Freenode you need to look for an entirely different app to migrate. With IRC or any federated network for that matter you point to a different server and its business as usual. See how fast everything moved over to Libera over the past few weeks.

It's true, I haven't factored in smartphones. That still doesn't invalidate the argument. I still believe it's quite narrow-minded to choose typefaces based on a 270+ ppi device. It still excludes a quite significant amount of users, and probably most desktop users.

I don't think high-DPI screens are as commonplace as it is continuously being repeated here. The only relatively common high-DPI screens are on the macbooks and higher end 13/14" laptops (250-300 ppi). If you move away from laptops and on desktop-sized screens (25-27") ppi quickly plummets. A common market monitor size/resolution combination is 27" at 4k resolution. This is roughly 160 ppi, although better than 1080p ~100 ppi screens is still nowhere near the pixel density of a macbook. So even on 4k screens the legibility of a heavily-serifed font such as Garamond is questioned. There is probably ONE desktop monitor with >250 ppi I can readily find* (Dell UP3218K) and that's almost $4k !! I'd say the author's argument still stands for anyone not on a ~$≥1.5k laptop. It's the same story as "we don't need subpixel antialiasing any more". Yes it's an ugly hack and yes you definitely don't need it on 300 ppi screen. Fonts are still going to look fuzzy on anything else.

[*] In the UK: https://uk.pcpartpicker.com/products/monitor/#r=768004320,57...

I think the generally accepted way to do that would be a container image running a relatively old distribution. This is exactly what python packages do when they need to distribute binary packages on linux [0]. You are supposed to compile the package in a container (or VM) that runs CentOS 7 (or older if you want broader support), although now the baseline is moving gradually to Debian 9.

[0]: https://github.com/pypa/manylinux

Going through the trouble of implementing CGNAT and skipping IPv6 seems like a partially degraded service for the end user though. It's becoming common practice for ISPs to slap all the users between two layers of NAT and calling it a day. You can't run essentially anything on your network (not even an SSH server) without having to have a server on standby and reverse tunnels. I know there are not enough IPv4s but at least let me having the option to pay for one. Or, you know, give me an IPv6. Otherwise it's practically a networked content consumption service at this point. It's 2021, the "IPv6 is complicated" excuse must stop at some point.

Proton is Valve's Wine integrated into Steam, it's essentially vanilla Wine plus some extra patches (that will eventually work their way upstream) and libraries to make your life easier. You enable windows compatibility for a non-native game and it will run in its own prefix. If you are using Steam for games there is no real reason to use a different build of Wine although you can definitely do so. In fact different custom builds are out in the wild that can plug into Steam and be used alongside the official Valve builds.

I can't see why a third-party program cannot be used with Proton. You can just add it as an external program and enable windows compatibility as you would with a steam game.

I believe this argument is slightly weak. I understand that the ecosystem is very diverse but even on Windows most new games only officially support Windows 10. If you're on 7 for any reason then it's your problem if the game doesn't work. Similarly if you're willing to go down the Linux route developing and deploying only on Ubuntu, for instance, can be regarded as a "single platform". It's my prerogative to use whatever I want on my Linux box but then it's my problem to make sure I have all the required components available for my bespoke setup. I haven't used Ubuntu in years but give me a "Ubuntu executable" and I'll find a way to make it work on my desktop. And if you don't want to limit yourself on Ubuntu Valve is now rolling out their "steam runtime containers" which are reproducible environments for developers to target.

There are still issues with the drivers, I'll give you that. But at least AMD/Mesa is moving fast to adopt features. NVIDIA is going to be NVIDIA but at least they are not skimping on implementing OpenGL and Vulkan extensions.

Qalculate (https://qalculate.github.io/) is quite good for linux/bsd

I don't believe the main problem with gaming on mac was the architecture or their anaemic graphic cards but rather their non-standard mac-only graphics API (metal), their deprecation of OpenGL, spotty support of Vulkan (if any) and removal of 32-bit support (for older games). The first three are not really a problem for big engine makers, as they can afford to implement additional backends but it is an issue for smaller studios and indie makers. 32-bit support is probably going to be less important (unless Rosetta can also translate x86 only code). It's good that they packed a decent graphics subsystem in their new chips but that's only part of the solution.

I believe their main concern is to bring iOS games to macOS rather than bring new games into the platform. Let's be realists here, iOS games bring in the cash. If they can run it in another form factor with potentially better graphics then even more money in the long run.

It's common occurrence having software dismissed as second rate because it's "ugly" or non-conforming to current design trends. Although form and function should enhance each other we've now reached a point where changes to form actively harm function. Toolbars are gone, menus are gone, icons are abstract outlines of what they represent, discoverability in GUI applications is hampered. I can find quite a few examples of applications both mobile and desktop that have become increasingly frustrating to use for no benefit whatsoever. "Where has this button gone? I'm sure it was here before"; "Oh I need to click the nondescript three-bullet button, then tap actions and there it is!"; "But the colours are now nice". Especially in a productivity tool I'd rather not have the interface change every other release because it's "ugly" by some abstract metric. Although I believe the ribbon turned out to be a decent design I'm fairly certain that wouldn't have been the case if Microsoft had changed again to something completely different within a release.

So, yeah... Please give me ugly but predictable interfaces.

As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.

The relevant bits are available in the WSL2 fork of the linux kernel. I know MS is probably doing that for access to GPU hardware for ML/AI training but I'm wondering (and hope) if this would indirectly benefit the DirectX implementation efforts in Wine.

Except high density displays are not really that common outside smartphones and the Apple world. It's probably safe to say most people still work on regular 1080p monitors at 90-100 dpi or at best on 1440p with slightly higher dpi. So an SVG with design resolution of 512×512 will look like a blurry mess when scaled down to 16×16. We'll get there eventually but optimising for low-density displays is still a very valid and reasonable thing to consider.

> I don’t think asking for a graphical shell for TeX/LaTeX is unreasonable.

There is one: it's called LyX [0]! You take care of content and LyX will abstract away most, if not all, TeX stuff. I've used it in the past for quite extensive documents and it is quite frictionless. It is never going to be a word processor but I believe LyX strikes the middle ground quite well. This [1] looks quite "graphic-y" to my eyes

[0] https://www.lyx.org/

[1] https://www.lyx.org/images/about/aqua.png

Albert, maybe?

https://albertlauncher.github.io/

It's interesting to see how Valve alone changed the landscape when it comes to gaming on linux. For once someone, no matter their motive, put their money where their mouth is and actively contributed towards that effort. I know, they're standing on top of years of effort of the open source community but still, they managed to bring things together and ship a more or less painless experience with Steam. Between Steam supporting linux, contributions to various related open source projects, linux VR support, employing the author and DXVK and streamlining the use of Wine if there is anything as customer loyalty, hey they got it from me!

That being said it's not all roses. There are lots of titles are using weird anti-cheat methods that are so intimately integrated with Windows that is unrealistic to expect them to work at some point with Wine, if ever. Unfortunately these titles also tend to be fairly popular so if you're into these competitive games, no luck.

On a separate but related note I see lots of people complaining about NVIDIA GPUs. Although personally I've never had a problem with their cards their stance and drivers are problematic at best. I'm fairly certain that a good quality open-source driver for NVIDIA is possible but given how unwilling NVIDIA is to cooperate I wouldn't hold my breath. Seeing how far AMDGPU has come the last years my next GPU won't be NVIDIA (voting with your wallet and all that).

I'm fairly certain Gajim supports most of the standard XMPP features one might expect from a client [0]. I use it daily. Granted Jingle audio/video is not working in a cross-platform fashion but I'm fairly certain file transfer through Jingle does. HTTP file transfer is also fairly straightforward if your server supports it. My problem with Gajim is that it's not a turnkey solution. You need to adjust settings, maybe use a BOSH proxy if you're behind restrictive firewalls, manually enable OMEMO and deal with trusting and enabling keys. For instance I occasionally miss OMEMO encrypted messages (as in they cannot be decrypted) send from Gajim on a specific device. On the other hand Conversations does a much better job at hiding all this manual labour from the end user to the point that I can tell anyone: "just install Conversations; login into that server; done".

Pidgin is quite lacking as far as Carbons and OMEMO is concerned. Last time I checked you need to install custom plugins, issue text commands to configure the plugin, issue different commands to trust/distrust OMEMO keys etc. It's a lot of work which is probably partly due to the fact the libpurple tries to handle a lot of different protocols using a more-or-less transparent API. It does a fairly good job with most protocols (including proprietary ones through plugins; like hangouts [1]) but unfortunately its XMPP support is not really up to modern standards without effort (much more so than Gajim).

Dino is good and I think they solved some OMEMO compatibility issues they had. But it's Linux only. This is not necessarily bad since they can do much better work by focusing on a specific platform, both functionality- and aesthetics-wise. It's too bad there isn't anything comparable on Windows/Mac.

[0]: https://dev.gajim.org/gajim/gajim/wikis/help/GajimXEPSupport

[1]: https://bitbucket.org/EionRobb/purple-hangouts/wiki/Home

My experience is kind of similar. Unfortunately the way Rust interacts with memory is quite different from how Gtk does (and most GUI tool-kits to be fair). The end result is a kind-of awkward battle between the Rust borrow checker and the internal memory handling of Gtk+ leading to loads of Rc<RefCell<T>>. This makes also quite hard to implement custom Widgets in an intuitive way. In Python or C++ you would subclass the generic "Widget" class and start implementing the bits you need. With Rust things are slightly complicated; you can't just implement the IsA<Widget> trait and call it a day; at least not a straightforward way. Hopefully gnome-class [0] will probably solve this problem eventually.

That being said it's been a while since I've used gtk-rs so it is entirely possible things have changed. I'd love to be corrected if that's the case :)

[0] https://gitlab.gnome.org/federico/gnome-class/

It's a shame that IRC usage is dwindling especially in techie circles. However I can understand it if it doesn't work for them any more although in my opinion IRC has a lot of moderation tools available. In any case, the "problem", of sorts, is not abandoning IRC but what comes next. The web is choke full of proprietary communication protocols that cannot talk to each other and you have private entities acting as gateways to online communication. Instead on relying on protocols and let clients decide how they connect to the network you have users being herded into walled "communication" gardens. This goes beyond Slack or Discord or chat-app-of-the-month. Having a flagship open-source project behind a proprietary platform for communicating with the users and developers can't help but leave a sour taste in the mouth.

Well, at least there is still Matrix to hope for.

I was never aware of the ping attribute but now it makes me wonder what was the rationale behind standardising it. Is there any particular legitimate (ie. non-tracking) use for such a feature? It would makes sense, of sorts, if there was a policy regarding the target of the attribute but as far as I can see the browser can ping literally anything.

I would still like to know what kind of features are unavailable in Firefox to warrant a complete block on the browser. This would also help Firefox developers to implement them or fix the bugs. I mean I always see "Firefox does not implement all the features we need for our cutting edge web app" but I've yet to see anything more specific. Do any of you with more frontend experience care to comment?

I don't know if this is nostalgia talking but there is something particularly attractive about the BeOS and Haiku desktop both in terms of design and aesthetics. The interface actually has a certain depth and this is consistent across icons, windows, dialogs, menus, buttons, etc. It's a shame that interfaces nowadays are completely flat. They are almost... expressionless and with the exception of the odd drop shadow they completely lack a third dimension. When I first learned of Haiku (and BeOS), back when Gnome was in the 2.x days, I was so impressed by the interface that I installed a look-alike desktop and icon theme. I used it for quite a long time until GTK+ 3.x eventually became prevalent.

Probably this refers only to the pre-compiled builds offered by Mozilla? The distribution packagers build Firefox from source before pushing them to the repository so it would make sense to use the default compiler for the distribution.

On a relevant note, is there any linux distribution that defaults to clang instead of GCC? Up until a couple of years ago the kernel would not even build with clang.

> Disney and extended copyright is the reason you don't see more Star Wars content. If Star Wars copyright had expired, you will see a lot more content about that fictional universe.

When Disney acquired LucasFilms my first thought was that they will probably kill the Star Wars Extended Universe and in a sense they did. There was a tremendous amount of Star Wars comics from Dark Horse during the 90s and 00s that built upon the whole Star Wars mythology. The "Old Republic" series (including the games) is probably the most enjoyable Star Wars story I've ever encountered but alas everything was rendered non-canon when Disney worked their magic. Now everything Star Wars revolves around the original chronology rehashing the same things over and over again in a "panem et circences" manner with no hope of seeing any new stories of any kind.

It's a shame

I don't understand why these should be mutually exclusive. Starting from a common parseable markup you can have both responsive HTML for browsers and formatted PDF for print. Why don't decouple content from presentation?

As it's evident from NAT they can track even behind a single IPv4. As long they know your prefix the privacy extensions don't really help. Of course one could have a dynamic prefix similar to dynamic IPs residential ISPs use. It's funny, in the past a static IP was considered a valuable feature for a residential internet connection. Nowadays, I'm wondering if dynamic IPs are more viable from a privacy perspective.