This is why "side loading" needs to be normalised as a completely regular form of app installation. Far more resistant to censorship than relying on profit driven corporations "fighting" on our behalf when it suits them.
Except they do. One just has to look at the inability to keep JPEG-XL mainlined in Chromium. Sure, some forks still have JPEG-XL, but it's effectively gone at this point.
It's kind of ridiculous that the US has held onto pennies for this long. New Zealand phased out our 5 cent coins back in 2006, approximately 3 US pennies worth at present.
I'm gutted; I absolutely love the Sculpt Ergonomic keyboard, especially with the optional slightly inverted slope, it's even more comfortable than previous ergonomic keyboard models. And I've been exclusively using Microsoft ergonomic keyboards for over 20 years, started in my late teens. Tempted to buy a second Sculpt Ergonomic keyboard as a backup for when this keyboard eventually dies, hopefully not for a long, long time!
I've also heard of a trick of integrating WoL with DNS, where if the server requests a lookup for a local IP, it'd send WoL packets to the destination. You'd probably just need to set the TTL for the server's IP very low so that it doesn't get cached.
I've had zero issues deploying .Net on Linux, whilst developing in Windows. The docker support is really good, if you want to go that way too, and didn't need any platform-specific shenanigans to get working.
JSON really is a terrible serialization format. Even JavaScript can't safely deserialize JSON without silent data corruption. I've had to stringify numbers because of JavaScript, and there were no errors. Perhaps that's the fault of JavaScript, but I find the lack of encoding the numerical storage type to be a bug rather than a feature.
I use branches gratuitously, and push to my forks regularly as you do, but I also do interactive rebases and edits when preparing to push to upstream to clean up my mess.
Have to say that at least it was simpler to work with than digital displays as a user. I still have trouble with digital displays, EDID, getting __nothing__ when a signal is out of range, whereas you might get something you can decipher from a CRT. Displays that don't wake up, displays that blink off and on, and all sorts of other timing issues and such. It can certainly be a mess for drivers too, esp. in the hobby OS space.
It's basically the digital equivalent of body shaming. And this sort of thing will feed into biased AI algorithms, and shape the world of "acceptable media" in the years to come. It may seem harmless on the surface, but the ramifications run deep.
They did not do this out of generosity or good will to small businesses. They did this for the PR, knowing that they're still rolling in the cash like Scrooge McDuck from all the years they've been milking it, and will continue to milk it, whilst looking like they're giving a handout. And it honestly looked like it worked from the comments of people defending their stance.
I quite like the convenience with the Kore remote for Android, great for my home cinema setup. But unfortunately updated packages on Ubuntu since moving, and now audio doesn't work. I really hate Linux audio, what a mess >_<
Of course not. It just gets more to the point of the original article. Whilst publishing and upstreaming driver source code for Linux is awesome, it's still only a half-measure in the overall picture of things being truly open, and we should try to demand more from hardware manufacturers. But we don't really have much sway in those regards, and it's disappointing as an OS-enthusiast, and a Haiku developer.
There's a difference between drivers being upstreamed to the Linux kernel, and a datasheet being available. The source code is not the datasheet, and if there are bugs in the driver, where is the datasheet to compare the implementation to?
When it comes to hardware, source code availability is not sufficient.
Other OS platforms can have different driver architectures, different kernel ABIs and other platform quirks in comparison to Linux, and having to reverse engineer a driver for another platform from a Linux kernel driver is not very open. And then there are licensing considerations to be taken into account as well.
Linux is not the only opensource operating system in existence :-/ And for a project like Haiku, we don't have the people-power to reverse engineer Linux drivers, and again, the question of the GPL also applies when our kernel & drivers are MIT licensed.
Visual Studio does a lot more than just visual designers. The integration for .NET is fantastic. And I love Visual Studio Code for everything else :) Visual Studio still has value.
I'm especially excited for this as Realtek codec support, at least from looking at the Linux driver, has a substantial quirks layer. The datasheet right there on the page makes it quite likely that if it doesn't work out of the box with the generic codec driver in Haiku, much more likely to get it working.
I do hope they don't switch back to the Realtek codec in the future.
I see a lot of exceptions versus error types/values, as if there's no in-between of exceptions and error types/values. There exist languages that support both. OCaml has both optional values and exceptions. C++ with std::expected. C# with the work on nullability/nullable reference types, and already with nullable value types.
I use https solely for fetch, and ssh for push. Then the only credentials are the ssh keys. Does mean I need to edit the remote after fetching, but I'm pretty happy with that.
Perhaps I don't understand the UX developer role enough, but I would imagine it involves research and user engagement. Perhaps the role is then too narrowly defined? I liked the comment about Word's competitor being the previous version, so that changing the UI/UX would need to provide tangible user benefits. I think Microsoft lacks some of that these days (early Windows 11 builds have been proof of that failing in my experience thus far).