timidger

Beyond All Reason

From the footnotes/references:

2. Forthcoming article, Kris De Decker, Low-tech Magazine.

The veracity of their claim is still in question, but based on that I'm going to assume good faith that they have facts to back up their claim. I haven't checked the rest of their citations yet, but based on their quantity I'm going to assume the rest of the article isn't sloppy either.

Your solution to a privacy problem vis-a-vis mega corporations involves moving your transaction to a public block chain?

It's not (just) that python is "easier" to learn than python (which I dispute - lisp is as easy to learn as a first language as any other. Depending on the language it may be a difficult second language though). The world had also changed radically since it was introduced into the curriculum:

"Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme — it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want. But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course. So the good thing about the new 6.001 was that it was robot-centered — you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc — you have to build in robustness to the system, in a different way than the one SICP discusses. And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all."

https://www.wisdomandwonder.com/link/2110/why-mit-switched-f...

I think the opposite, though I admit I'm very negative on NFTs and crypto. IIRC their NFT snoos came out well after the NFT bubble. A probably not insignificant amount of Dev time went into this, and I can't imagine it got much traction.

Of course, it was only this year that I realized reddit even has these snoo avatar things on people's profiles. So maybe I'm wildly off

I always love to see reddit leaking onto this site

you sure nginx is even going to be around in, say, 15 years?

Considering it's been around longer than that, yes I think it will be around in 15 years

I have no doubt these technologies will improve, but there's another argument to be made. The tech will get better and we'll be all the worse for it.

Stoll argued the tech will not be good enough, but paid little thought to the ramifications of the technology succeeding. The arguments against LLMs like Bard and ChatGPT that I have seen are assuming they'll be successful.

They'll become less stupid, but the problem is not that they are wrong but that they are, at present at least, unassailable. You cannot fact check through most of the normal means. You can not research the publication or the author or the date the words were written because that has all been stripped away.

You could check other sources (eg old fashion google) and put in the leg work, but as these get better that will feel less necessary - potentially exacerbating this problem.

That's not to say they aren't useful. I used Chat gpt the other day to get some work done and was impressed. However this was work easily verifiable because it was technical and had immediate feedback when the ai inevitably gave me slightly incorrect code. The same can not be said for facts, figures, and arguments of thought.

I agree, that is a weak reason to dislike macros.

I dislike them primarily because of the additional complexity they add that isn't always justified. All of the more complex macros I wrote I regret, especially the one I did at my last job since now others had to maintain it.

Some macro use can be justified, eg serde. But I try to avoid using proc macros where I can (and certainly never try write one anymore)

It was probably very true 10 years ago, for some of them it has become less true

Lack of server side decorations in the core spec, and limitations of wlroots, are unrelated so I'm not sure what they're getting at (except to support the larger idea that Wayland is poorly designed, which I disagree with. However, I think I'm a little too attached because of my involvement)

Author here. Certainly part of the ugliness of wlroots-rs is my fault (unsafe code + macros is not a fun combination).

However, I tried quite a few ways to make this safe and ergonomic. Perhaps some better way exists that I missed, but even if a solution exists the work needed to implement it is very, very boring.

wlroots is very much a C API, but I admit I was expecting it to be easier to use from Rust and is my current biggest criticism with the language.

Normal Rust is normally not this inscrutable - however it does have a lot of features that could make it as hard to read. It requires a certain amount of discipline that you don't see in simpler languages like Go. I for one never write macros if I can help it anymore.

Depending on how you want to define fraudulent, it already has https://youtu.be/eYzzPBq8GDU

This is a client library only (at least according to the title). There would need to be an equivalent server library implementation, not to mention all of the necessary non Wayland protocol code (libinput, drm, etc). Still the easiest means to port StumpWM would be to use c bindings for wlroots

I think part of his Rust criticism was towards the attempt to make Sway use wlroots-rs and it not fitting his idea.

That was never a goal, not for Sway and not for wlroots-rs.

I wrote that to port Way Cooler, it was no different from the other wrappers in other languages that exist.

I use it to check if an app uses xwayland when I use sway

Do you have a link to that discussion?

I haven't done any Linux work (except for some stuff with device tree that I've mostly forgotten), but that post I made about Way Cooler may not be generalizable to all C APIs. It's also possible that I simply was not creative enough with my API design - since that blog post a few people have reached out with alternative designs that avoid some of the issues I ran into. I haven't dug into them however, since I'm no longer interested in working on Way Cooler.

It's not so much "Rust can't represent this ownership model" as "this ownership model is basically orthogonal to Rust's so you have to put much more effort in to write idiomatic Rust code compared to writing it in C". I would love for someone to come along and prove me wrong with a better wlroots wrapper.

Also, Wayland composites are much, much simpler than the Linux kernel, so that train of thought doesn't necessarily scale out.

That is not a good reason for choosing such charged language. You can get your point across without comparing a venerable (if flawed) programming language to one of the most feared class of diseases that kills millions each year.

I think there are good points you make that people should hear, but less people will listen if you turn them away by making grotesque comparisons.

No traditional utility company does what Google has routinely shown to do as in the original post though. There's still a bill to pay and expectations of reasonable service (I assume if I just left my tap on and drew as just electricity as I could I'd eventually get some phone calls and massive bills) that allows these companies to be profitable.

Google isn't at the point it needs to be nationalized, but something needs to be done to limit the fallout that occurs when users are kicked off essential services with no recourse.

I found your point hard to agree with, until I mentally replaced "HTML" with "bash" at which point I was enlightened of how important context is.

Though I was hired to work with languages $X and $Y at $dayjob, many, many bugs slip through because bash is used as glue for languages $X and $Y. This was true of my last job too, the only difference is that in my current job we don't have a resident bash expert to call out issues in code review.

I've always hated bash, but it's "essential" complexity when dealing with a modern Linux system. Technically it's within our domain to change, but for various reasons time and time again bash wins out as the de-facto glue holding infrastructure together.

Which you'd never write in practice since `expect` exists

Out of curiosity what's wrong with git add -i? That's what I use to stage parts of a file.

As a software developer that, at one point in a job, was forced to confront hardware head on because the code I was writing was firmware, I'm guessing they mean something like Kermit. A simple tool to get the output from an embedded device.

I'm not convinced totally that's the case, but I'm definitely more open to that idea after that job. I've stopped using macros in my side projects and I avoid projects that use them now.

Clippy catches a lot and I can't imagine coding without rustfmt.

But there's more to style guides than formatting and Clippy lints. Some designs will pass Clippy (or worse, lead to Clippy warnings far past the point where a redesign is economical) but be inefficient, inflexible, or have a poor effect on compile speeds.

One major problem I experienced in my last job (where I worked on production rust) was the insane amount of macros and proc macros used. This was an originally C++ heavy shop so they leaned on it more than, say, a python shop moving to rust would.

This led to terrible compilation times and confusing code only certain engineers could maintain (I'm guilty here - I've since left and I know of one proc macro I wrote that will cause headaches to anyone who uses it).

We need an opinionated style guide. The language is so complex we probably need multiple, with different trade offs.

That's because they implemented egl streams, nothing has changed majorly since then. There's been a lot of talk, but no action towards unification. The ball is entirely in Nvidia's court and they continue to work together on this.

Because the version of web browser and the kernel more or less doesn't matter because they care way more about backwards compatibility than the "vast majority of software".

The kernel doesn't break user space. Web browsers' api generally remains backwards compatible (how long did it take to remove flash - and you can still install it if you want!)

Funny... filtering out these type of extensions was my intern project 2 years ago at Google.

Your edit to your original comment was important information I was missing - you are correct that that would probably work.

With how wlroots-rs is setup it does require the upgraded resources to not be leaked because their drop impl decrements the reference count.

Regardless, this was obviously only one part of the problem I was running into. As well, as can be seen, it's very complicated trying to ensure this is all sound and it's no longer worth the headache.