sspiff

> Why does it seem like such "macOS bad Linux good" comments always compare the default macOS experience to a personalized Linux environment?

I'm not, I'm comparing to an unmodified, standard config Gnome or Plasma.

I also use Sway, and I'm pretty sure I've spent less time customizing/configuring it than my Mac.

I've not had breaking changes in Linux for a long, long time. I generally use either a completely unmodified, default config Gnome, or Sway with my own config.

I've used a couple of different desktop environments or window managers over the past few decades, but these days I either stick with the default (which is so often Gnome) or use Sway, where I can just copy in my config file and everything works exactly as I'm used to.

No, I do not, at least not on macOS. Because the experience is so horrible, perhaps.

I generally have one big window or two windows side-by-side on Linux though.

SIP is the default though. Turning it off is an option for some, for now. But Apple has clearly indicated they're moving towards a more restrictive ecosystem through there actions for a long time now.

I'm a software developer at a company where ~50% of the staff is a developer and our IT fleet management enforces SIP. This simply isn't an option for us because of security requirements from our customers.

I personally much, much prefer the UX on Linux. I may be suffering from some kind of Stockholm syndrome as a long time Linux user, but I have to use macOS for work and it absolutely doesn't work for me.

I find the UX quirky and akward to use. I hate how the window management works. I hate how annoying it is to get two windows to show side by side. I hate how there end up so many icons in the menu bar which are entirely unhelpful. I hate how space inefficient the dock is, but when you auto hide it, you can no longer see the notification counts at a glance.

I would honest to God rate macOS UX a 2/5 for design and a 5/5 for QA.

Yes, quite a few Linux games still run on OpenGL, even recent ones[1]. Most support Vulkan as a backend as well, and this would be preferred once supported on MacOS, but that is still a work in early stages of progress.

[1] One example is the Clauswitz engine from Paradox Development Studio, which is used in all their games.

I largely agree. My goals have shifted from having an impact moving the technology world forward to not being frustrated and depressed from work and getting enjoyment and satisfaction from personal small projects with no deadlines.

Since having kids, most of these have shifted from a few months in time to a few years, but they are unambitious, poorly defined and unimportant so who cares if they take a little longer?

My main goal at work is not getting annoyed or frustrated and getting paid well for my time.

This is nothing new though, this has been true since the rise of TV and things like top of the pops. Because guess what? People prefer pretty people.

Once artists became visible, this was inevitable. The pretty people were going to become popular regardless of whether the music industry got involved or not.

Publishing an implementation of a proposed web specification is how all web standards are created or evolve. The same thing happens with WebGPU, WASM, and many before them. Usually with a prefix (ms-, moz-, webkit-,...) and/or locked behind a config setting before standardization.

What is different this time other than it being a feature that is considered user-hostile?

That's not to say we shouldn't oppose this feature, I just wouldn't be up in arms about an implementation existing.

Interesting, but I don't understand how it does taxes. I live in a completely different, much more income tax heavy nation than the US. It shows me large tax returns in the simulation which are orders of magnitude higher than what I'm actually getting. How do I disable or change these?

Edit: Found the taxes tab, but it seemingly didn't apply the income tax rate I provided in the plan creation "wizard"?

While I myself am partial to noisy vibration generators, it should be noted that vintage Porsches are the most common form of classic car EV conversions.

> To keep an eye on the housekeeper.

If you can't trust your housekeeper not to steal from you (or do something else you want to catch on camera), you either hired the wrong person or are not paying them a fair wage. Either way, it's a you-problem.

Same, it just works on my Debian powered home server with 5800H with just the Mesa ICD installed.

Not that it really matters for me, I only run wgpu compute stuff over Vulkan for my experiments.

Some 8xx series are well supported, but mostly 835 and 845. QC does release better quality sources for mainlining AFAIK, but I haven't seen any efforts related to newer chips land.

When I last checked, the mainline kernel support for the 8cx was EXTREMELY limited. Having messed around with lots of ARM based devices on Linux in the past, I would not bother with this one. Especially given that rather unimpressive battery life.

I'd love a modern ARM based Linux laptop, but I also know that unless it's got mainline kernel support or a dedicated Linux friendly vendor (like Pine) behind it, it's lifetime and updates are going to be extremely limited. And that doesn't even consider graphics API support, which will have an impact on rather basic things, such as YouTube video playback.

Honestly, the only viable ARM laptop with good battery life and modern day performance is an Apple MacBook Air or Pro, which has a very impressive community project behind it. But even that is still incomplete and might peter out if some key figures burn out or become uninterested or preoccupied with for-pay work or whatever.

I find that battery life extremely uninspiring. I wonder if that's because of Windows, JetBrains or a combination of both.

I run a x86-64 laptop with Linux AND decicated graphics (Ryzen 6850u and Radeon 6800S) and get 6-10 hours of battery life while developing.

Granted, that's after quite a bit of tweaking - I've configured my monitor to go to 60hz, limit the CPU to only 4 cores/8 threads and 2200MHz while on battery. I write Rust with rust-analyzer so the CPU is constantly in use, and my browser of choice (Firefox) is far less optimized for battery life than any chrome-based browser is on Windows.

This gives me a laptop with no concessions with regards to compatibility and it's probably running loops around this ARM based chip, even when running at my tuned-down power settings.

I'd love to have a Linux compatible ARM laptop, but if they don't give you real world double digit battery life, why bother?

This would never land in a factory image or upstream Android, but it has a reasonable chance to become part of projects like LineageOS, given enough user demand for it.

Depends on the games maybe, I don't play competitive online games. Most stuff that doesn't work is because of anti cheat or DRM being intentionally incompatible because it's impossible to guard against kernel modifications on Linux.

Her work on Mesa & free drivers is amazing, truly seems like a generational talent.

I bought a Steam Deck, I used it a bit but honestly not as much as I expected.

I did however finally manage to dump Windows from all my machines, apart from my VR sim racing rig, and now play everything on my Linux desktop or laptop. If it doesn't run, at this point I just pick something else to play. Steam Deck has pushed the state of the art of Wine/Proton/DXVK/... so far it's mostly just a plug and play experience, I've not had any issues at all. Often runs more reliably than native Linux ports.

I'd love to tell you what it did suboptimally in my usecase at the time, but I no longer have the code and it's been so long I don't remember the specifics.

Like I said in my earlier comment, it was so long ago the performance remarks may be outdated and the project may have resolved them.

I would like to give Futhark another try, but I need easy and portable integration in either Go or Rust, and as far as I can tell, that's not the case today? For my current project, I ended up selecting webgpu for my GPU compute needs.

Most GPUs run threads in groups of 16 or more, with one instruction pointer shared by all of the threads in a single group.

So if some threads need to take an IF-branch, and some need to take an ELSE-branch, both paths are executed in sequence, with all threads in the group executing in lock-step, and a per-thread mask disabling the effects of the instructions that aren't needed for each specific thread.

If you do this enough times, with sufficiently complicated branching, you'll quickly negate any efficiency gain you get from the massive parallelism.

A GPU is a really, really fast map hardware processor. Reduce steps are not good at utilizing all of the silicon hardware available IIRC.

I used Futhark in the past. It's probably been 5 years or more, so a lot may have changed since then.

It's absolutely a much lower barrier to entry, especially if you are familiar with functional programming. However, it also leaves a lot of performance on the table, and I found it to be hard or cumbersome to integrate with languages other than Python at the time.

And you're still stuck with CUDA (which is single vendor) or OpenCL (which is a pain to set up on most consumer systems, and has very lackluster driver quality for a lot of vendors). I would have liked that by now support for Vulkan compute or OpenGL compute shaders would have been added, but alas.

Does anyone have any indication of ProtonVPN doing something fishy? I always considered them fairly trustworthy and they offer a free option.

Ah the memories! I used to run JLime and NetBSD on Jornada and MobilePro machines. While definitely not perfect, they were really nice and useable, and far more portable than contemporary laptops.

You could run X11, they had PCMCIA (for wifi and extra storage), and were just such a wonderful mix of weird and useful.

Glad to be reminded of those good times :)

> It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares.

I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend / system software development.

It's just that noone has been able to replicate that kind of success in the web-based frontend space.

This happened in the case of Rust and Go after LOTS of searching for better alternatives to C/C++ and later Java. There are a lot of failed attempts along the way, and some which find their niche but fail to displace the older generation languages in any meaningful way.

There has been TypeScript and Dart and transpilers that have tried to shield us from the horrors of JavaScript development, but in the end they still are too closely related to JavaScript and its runtime to truly displace it. I feel like we have an opportunity now, with WebAssembly, to move beyond these limitations.

If browsers and web standards move to a point where we can use WebAssembly as a first class citizen, without the need for JavaScript scaffolding, we could see the rise of a new crop of languages for the frontend. Perhaps even making it possible to remove JavaScript entirely and move it into a WebAssembly module eventually, to remove it as the default choice and put it on equal footing with new alternatives.

We could take the lessons we have learned from other modern languages, and apply them more natively to frontend problems and practices, with language-native tooling and a higher level of integration in those tools than we have been able to achieve with JavaScript.

As someone who used to have a cheap-ish 3x27" monitor setup, I can confirm neck strain on big triple monitor setups is most definitely a thing. Imagine combining this with carrying the weight a pair of technogoggles like these,and I think it could get tiresome really quickly.

Is there a list of unsupported syscalls and instructions, and how to add support for them for people interested in contributing?