gnulinux

No it won't Wayland protocol doesn't support it, besides Wayland has been here for such a long time. Pretending like Wayland is ready to replace X is like pretending like we can ban cars tomorrow and bikes will be good enough. It's completely delusional.

Yet nothing works on Wayland. This is the kind of stuff that boils my blood as a linux user. In my arch install I do not intend to uninstall X for the next decade or so. Every time I tried switching to Wayland it was a circus of dozens of bugs and workflow I use everyday for work being "not supported".

Is that someone RP'ing as an OpenAI insider? There is no evidence to suggest they're a reliable source. What am I missing?

It really is. Academia prioritizes quantity over quality. Western less so than Chinese, but nevertheless it's a problem in academia. Peter Higgs (the guy who predicted Higgs Boson) recently talked about it: "Peter Higgs: I wouldn't be productive enough for today's academic system" https://www.theguardian.com/science/2013/dec/06/peter-higgs-...

I watched that clipped and you're wrong it's a completely normal interaction. Murati says "we're always working on the next thing" and Altman jokes "haha that's such a diplomatic answer" and the interviewer is like "who paired these two?". It's just standard humor.

Haha yeah no I don't believe this. They're nowhere near AGI, even if it's possible at all to be there with the current tech we have, which is unconvincing. I don't believe professionals who work in biggest AI labs are spooked by GPT. I need more evidence to believe something like that sorry. It sounds a lot more like Sam Altman lied to the board.

> makes me question my s/e belief system

That's a good thing! Models are fit on data, data doesn't fit to models. This is like when people learn elementary music theory then go analyze some actual composer and it doesn't fit the model at all. Well kiddo the problem is that "music theory" is simply a model, a model people created after training some very limit set of musical data, everything outside of that data will probably behave different and you'll have to change your models.

If your software engineering model predicts Python would be unsuccessful, but there is evidence that Python is successful, this simply means your software engineering model is unpredictive and therefore must be revised.

They're cheap but they're not free. If you do it at literally every single rw operation at runtime, it's going to add up.

This is exactly me, I relate with this so much in so many layers.

I feel completely out of control and it feels like no matter how hard I try, no matter how diligently I plan things out, everything everywhere get worse all at the same time. If my tools were working N out out of M today, they will work N-1 out of M tomorrow and it's impossible for anything to get better.

It feels like any electronics I interact with are maddening nowadays. Yesterday, me and my partner needed to set up a timer for 1 hour, I set up it through our dumb kitchen timer, and my partner was wondering why I didn't use my phone timer. Look you don't understand EVEN LOOKING AT MY PHONE is a fucking nightmare at this point because there are going to be N notifications that need my attention.

"Lack of manpower" is not a valid excuse when it comes to Gnome/GTK. If you redesign your entire codebase every other year, break everyone's workflow you cannot cry about lack of manpower. Writing software is one of the most expensive human endeavors in the world right now and FOSS community treats it like they have unlimited supply of it. If you have limited supply of software engineers then you cannot afford to redesign your UI and you have to stick to your existing code.

> Open-source is built one patch at a time

This is extremely wrong. FOSS would be better if things weren't redesigned every other year from scratch. KDE, Gnome, MuseScore to name a few. I was a master of MuseScore 3 and the year I finally became 100%, they dropped support shipped the absolute shitshow that is MuseScore 4, broke every single one of my workflows and finally forced me to use lilypond full time. FOSS is a redesign-after-redesign shitshow just like big name software are. I just want my software to work today exactly the same way it worked yesterday and it seems impossible to achieve that.

> I'm sure that's true, but then where is the great modern Western classical music?

It's like literally everywhere! I almost exclusively listen to contemporary Western classical music (WCM) and it's never been more exciting and better. There has never been a time where there are so many different dominant styles at the same time. There are atonalists [1] like Unsuk Chin, Jennifer Koh, Charles Wuorinen, Fred Lerdahl. There are neo-Romanticists like Jennifer Higdon, Michael Torke, Thomas Ades. There are minimalists like Caroline Shaw, Max Richter, Bent Sorensen, Christine Southworth and their ur-father Philip Glass who still writes music at 86.

If you're interested in my full opinions about the cultural force of contemporary WCM please read this [2] HN comment of mine.

Seriously contemporary WCM is awesome. It's very cliche but "if you don't like it, move on".

> In my opinion, this is a racist response by mainly European composers to the popularity of Jazz music which is associated mainly with African Americans, from whom the source originated. They were jealous of what they perceived as the novel rhythms and harmonies, but instead of building off that or inventing something new that still had rhythmic and harmonic value.. they did this

Meh, I don't think this is true at all. They're just entirely different artistic traditions. Just because haiku exists doesn't mean American novels can't.

I don't dispute that tons of normie classical music listeners (like r/classicalmusic) are racists/elitists. These people almost exclusively listen to old German common practice stuff like Bach or Mozart. They pretend that 18th century German music is somehow superior to everything else. Almost none of them would consider Ligeti or Glass even classical music. This is not the contemporary Western classical music scene at all. It seems like you may not have a sophisticated enough understanding of this subculture, imho.

[1] mostly Ligeti/Messiaen inspired people as opposed to Serialists

[2] https://news.ycombinator.com/item?id=37424409

This is the kind of thing you write once to abstract out async things in a function and call it a day. It really isn't that bad. Besides you can just use:

    smol::block_on(async {
        println!("I'm async!");
    });

if smol is an option.

In these debates I find myself very confused. I feel very comfortable with async ergonomics in Rust. It seems like the argument against it is that it has poor ergonomic... but how? It's rather straightforward to go from sync to async and async to sync you just have to code the strategy in. If you're in sync and need to run async, you need to run it in some executor (either in threads or in single-thread concurrency or something else). I've been writing async code in Python for years I'm truly missing what's so bad -- or even different -- about Rust async. What am I missing? I'll continue to write async code because it's pretty nice.

EDIT: People talk about swapping executors etc but it seems like 99.999% of the programming applications you don't need anything like this, nor does something like Python supports this anyway and we're all fine with it.

WebAssembly goes weeell beyond browser. It ensures consistent computation among all platforms including browser, desktop (linux/windows/osx), phone (android) and iot (ARM, others)... except iOS. It's closer to JVM than anything else but really it's already so much more universal than JVM which is mind blowing.

This is great (I love WebAssembly). I just wish there was a way to run WebAssembly somewhat consistently between browser, linux/win/osx and Android. It seems like this fixes the browser and linux/win/osx part but no Android. Frameworks like emilk (i.e. egui with eframe) can do all three but packaging is rather complicated. This solves the packaging aspect with no solution to Android. Eh, maybe one day we will get there.

Turing completeness is a bug, not a feature. After writing code in Agda for some years I was convinced that Turing completeness does more harm than good. Non-TC languages have a killer feature: their halting problem is solvable which means you can get arbitrarily strong guarantees from the compiler. The fact that you can't encode "while(true) { }" without putting "unsafe" doesn't make the language impractical, you can still implement algorithms without Turing completeness.

Moreover, using various forms of coinduction you can encode infinite computation even in non-TC languages.

> Ignoring everything else

This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.

> Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.

I've never seen a set of business people in a software company that cares about any of these things.

Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt.

When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee.

I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to.

People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.

Yes, this keeps coming up and people respond rather reasonably but people insist on not understanding. In software if something is similar to "cleaning out clogged sewer pipes for the 999,999th time" then it has to be possible to automate it. If I have a task to clean up my code, I'll automate it then it'll take <1 sec to do it. When people say "software is hard" this is not some sociological argument, it literally is a mathematical argument and the reaction should be either acceptance or automating it. If I cannot automate something I need to sit down and think about it the same I think about "Columbus setting out for the New World" or "building the Sistine Chapel" or whatever, i.e. as deeply as my neurological faculties allow me.

For "it's just kluding APIs bro" kind of arguments, I invite you to look at no-code and low-code products and report us how well they work. Is it easy to "kludge together APIs" in this fashion and does it produce viable products? Why? Why not? If it's so easy that it's close to being automated, why can't we have a UI like Photoshop to create API consumer apps?

What cannot be automated has to be exhaustively thought by someone.

Correct me if I'm wrong... If you buy an actively managed money market fund (such as VMRXX by Vanguard) when Federal interest rates go up wouldn't the return from your VMRXX assets also go up?

In other words, if in 2033 a stick of gum is $10000, which implies there was high inflation between 2023 and 2033, which likely means Fed increased rates even more, wouldn't that cause your rate of return to go above 5% and therefore roughly maintain the value of your assets (assuming Fed keeps interest rates above inflation)?

Uhhhh I've been talking about this for almost a decade now but people just judge me as being noob. Debuggers are nice but if you're a platform jumper they're more of a nuisance than helpful. I'm a programmer who shifts platforms very frequently and oftentimes use niche platforms with very little tooling. Once you do that for a long time you develop muscles to abstract out computation in a more fundamental way. There is always compute, there is always memory (N layers of cache, perhaps RAM, disk, remote etc) and chances are there is always some sense/form of logs. But sometimes there is no way to attach debugger. If one day you're writing code for GPU and the next day the same code is parallelized to 3000 tiny ARM vCPUs, and the next day the same code runs in WebAssembly you'd much rather not waste time playing around with debuggers. This is all to say debuggers are more of a specialized tooling and exceptions rather than the rule. I think software engineers would find some benefit learning techniques such as tracing, canonical logs, debugging logs, ad-hoc printf debugging etc. Just because noobs also do it, doesn't mean experts can't do it.

I have no problem with being unable to use debugger in WebAssembly, my primary approach to debugging is observable outputs from the system:

* Return value

* Logs

* Side effects

* Integration tests, unit tests

Desktop apps (SDL et al) don't interact with DOM but they thrive. I don't agree with this take at all. I do however think WebAssembly implementations need to increase storage size, with the current 10MB localStorage in Firefox/Chrome and 5MB in Opera et al, web apps are almost completely memoryless without cloud. If you could use a web app as a standalone app with its own memory that you can download/upload/sync it'd be much more useful.

... Yes? I make money writing code but I'd love to do tech journalism (no one would pay me money to read my stuff right now).

Oh whoops sorry about the typo!

Commitment! It's one of the most human of values. It's what makes marriages last 50 years no matter what kind of significant problems come up.

> The main thing is, I never want to give up, and I won't give up.

Just focus on this. When things at the most bleak, remember that you're not allowed to quit, so work around that.

Yep, I'm aware of these, I wrote about my thoughts about them here: https://news.ycombinator.com/item?id=37934604

No I'm not saying that at all, I'm just saying that if you need a function to handle all exceptions, the type system should be powerful enough to express that. E.g. in a webserver if you have a handler that needs a wrapper like:

    def wrapper():
        try:
            return handler()
        except Exception:
            logger.exception("unknown exception")
            webserver.status = 500

the type system needs to be able to determine that "f doesn't raise an exception". For example, one way to do this can be that all functions by default raise exception and we type:

    def handler() -> T: ...

    def wrapper() -> NeverRaises[T]: ...

then we have

    webserver_add('GET', '/handler', wrapper)

so that

    def webserver_add(method: str, path: str, handle_func: Callable[[], NeverRaises[T]]) -> None: ...

which is type safer.

Of course, here we need to specially handle `KeyboardInterrupt`, signals and exceptions returned by `logger` etc. I would personally recommend ignoring `KeyboardInterrupt`, and signals and type annotating `logger.exception` as `NeverRaises`. 95% is still better than 0%.

The second point is imho the single most important thing to know. Even if you have

  foo* new_foo() { return (foo*)malloc(sizeof(foo)); }

or something like that, you should always have `new_foo` and `delete_foo` otherwise you will leak memory and you will have use after free.

Right but it can still pull the "Windsorized mean" to a particular direction. E.g. if your distribution is

    -99, 1, 1, 1, 1, 1, 2, 2, 2, 98, 99

and you "Windsorize" your mean, you'll pull it towards one direction.

Here, we get:

    mean: 9.91
    median: 1
    Windsorized mean: 18.91
    truncated (Olympic) mean: 12.11
    2-truncated mean[1]: 1.43

as you see "Windsorized mean" is exaggerated on the positive direction.

[1] this is when I remove top and bottom 2 values and calculate the mean of all the remaining values.