Ooh! Or remember when a bunch of people acted like they had ascended to heaven for looking down on syntax-highlighting because Rob said something about it being a distraction? Or the swarms blasting me for insisting GOPATH was a nightmare that could only be born of Google's hubris (literally at the same time that `godep` was a thing and Kubernetes was spending significant efforts just fucking dealing with GOPATH.).
Happy to not be in that community, happy to not have to write (or read) Go these days.
And frankly, most of the time I see people gushing about Go, it's for features that trivially exist in most languages that aren't C, or are entirely subjective like "it's easy" (while ignoring, you know, reality).
>For an advanced git user, it doesn't offer all that much.
arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.
> I used it for a couple of weeks and can't say that it saved me any time or any amount of work
I would bet 5 figures that's a lie.
> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
So despite all this chest puffing, an appeal to authority would tip the scales for you?
There’s no need to be antagonistic. We’re all friends here :)
I am an unabashed jj evangelist and I don’t think they’re lying when they say it didn’t save them any time. Adoption costs might be small but they’re not zero. Some workflows are easy with either tool. And some people just don’t “get” it and struggle to adapt to a different mental model. That’s okay!
> So despite all this chest puffing, an appeal to authority would tip the scales for you?
I think GP was simply saying this would be a clear sign to them that if it’s mature enough to handle kernel developers’ needs, that’s a good sign it’s worth the effort to switch. It definitely would be! I can’t wait to hear if and when kernel developers start switching; it will be a huge positive indicator.
Clicked 6 links, googled stuff, couldn't figure this out. Makes me so, so, so irrationally upset. I do not get it. It's just basics? Thanks for sharing this.
I literally don't have the words to look down my nose at this. Former X11 contributor, compositor contributor, active distro maintainer. I just can't. I laughed. I scoffed. I incredulously looked at how much time someone with some braincells put into this.
I don't care, I'm saying it. Fuck your fragmentation whining. USERS WANT THEIR SHIT TO WORK. They expect high refresh monitors to work. They expect to be able to use a fking external monitor alongside their hidpi laptop. They need to be able to use actual fractional scaling, again with varying dpi monitors.
They want their shit to work reliably and not tear. Wayland delivers on this. Now. In a way X11 never EVER will.
God Jesus fuck i cannot believe how much people's time has been wasted on this bullshit useless banal conversation.
All this time has been wasted by Wayland developers insisting that if Wayland makes something impossible by design, then users who want that thing are simply incorrect to want it and therefore it doesn't count. Wayland does not deliver on basic shit working, and as long as "that's incompatible with Wayland's security model" is considered an acceptable answer, it never will.
Yes, this is the usual excuse for why Wayland is intentionally useless. Fun fact: The only difference between a11y software and really awful malware is that the a11y programs work for me, the user. If you make features impossible in the name of "protecting" me, you break things for me.
Yeah I'm so, just so upset XScreensaver can't lock a Wayland session. Jfc, good company there with a jwz link.
There's so much wrong with wanting or thinking an XScreensaver app would somehow work with a random Wayland compositor. But it does require ignorance of the exact security changes made to the model when moving from X11 to Wayland.
I can't. I can't. I should never waste my time in these threads.
Edit: i do also find it amusing how much of that manpage is dedicated to calling out how fragile and broken X11 is. You can't make this stuff up.
Edit2; I actually can't get over the irony of linking an app that notoriously has had a storied history because of X11's architecture. I can't name the number of time X11 sessions were not locked properly.
Whatever. Going to keep happily enjoying the basic features that every other desktop OS user expects that I get with KDE, gnome, cosmic, away, Niri, and more, in Wayland. Good luck unclutching y'all's pearls.
> I don't care, I'm saying it. Fuck your fragmentation whining. USERS WANT THEIR SHIT TO WORK.
...You understand that this is the strongest pro-X11 argument, right? As a user, I don't care that the backend is messy, I care that my stuff works on Xorg and doesn't work on Wayland.
Hm. So then don't use (systemd-)resolved? Alternatively, I've accepted that it's built to work with a decades-old ecosystem and that resolv.conf is effectively a generated, read-only-except-resolved file. And in turn, resolved's configuration is perfectly static and equally immutable. /shrug
My* only problem is that it's pretty good at what it does, and can be... more helpful than you might like at providing consistent global DNS resolution. For example, it's use over dbus makes processes in `netns`s susceptible to leaking DNS requests. Though arguably I should've been going more full-containery than just a netns maybe, given my expectations.
The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable.
Changing the IP address was also fairly simple in editing a file, but now there's networkd sometimes, and NetManager other times, and netplan too, and perhaps make sure your YAML file is indented with the right number of spaces in the right place…
> The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable.
In many years of daily-driving unix-likes and being an amateur and professional sysadmin, I think resolv.conf is the only time I've ever actually used `chattr +i`.
Yeah, you have to bump stuff and use packages that are actually compatible. Like Rust. Which does not do the insane things that Maven does, that the post author is presumably advocating for.
Oh the rich irony of using Maven. Maven, apparently has the same basic fundamental issues it had 15 years ago when [redacted] paid me to write a Maven plugin that would detect these version skews. I thought I'd just done it wrong because of the massive, sweeping number of places that it did things that were not just unfortunate, but were serious (you can imagine).
It is mind-blowing the things people come up with when it comes to Rust vs C conversations. The same colvoluted crap for years at this point.
No, just no. I'm sorry, Ive implemented countless custom formats in Rust and have NEVER had to side step safe/unsafe or otherwise sacrifice type safety. Just what an absurd claim.
Maybe for some binary (de)serialization you get fancy (lol and are still likely to be far better off than with C) but goodness, I cannot imagine a single reason why a config file parser would need to be (type)-unsafe.
The person you replied to didn't say that you had to bypass safe. This bug is orthogonal to type and memory safety, its a different issue.
The git bug in question could be written in 100% safe rust using as much or as little of the type system[1] as you want. It's a logic error when parsing a string.
I dev rust full-time, and I've spent a lot of time writing protocol parsers. It's easy to forget to check this or that byte/string for every possible edge case as you're parsing it into some rust type, and happens all the time in rust, just like it did in C or python or go when I used those languages. This bug (if anything) is the type of thing that is solved with good tokenizer design and testing, and using more small, independently tested functions - again not at all related to the type system.
[1] Although in rust you can arrange your types so that this sort of bug is harder to implement or easier to catch than in most languages... but doing that requires an up-front understanding that logic bugs are just as possible in rust as in other languages, as well as some experience to avoid awkwardness when setting the types up.
In practice I think a Rust project would have used toml which parses safely. The limitation there would be that toml requires strings to be utf8, so it couldn't represent all possible unix paths.
Which kind of makes it an unsuitable solution for the given problem right? Git is not free to (or at least doesn't consider itself free to) work only on a subset of possible paths.
Most applications could probably get away with not supporting control characters in paths, even git, because most file systems/OSes doesn’t support it anyway, as a user of control characters in a paths you can never trust it to work anyway.
_I_ would agree with you. But I’m also not a person writing a version control system for a kernel that still runs wrong-endianess hardware (I forgot which one we are using and can’t be bothered to look it up). And I think a major part of this is, that I assume that something is so insane, that people just shouldn’t do it and the people steering the kernel or git don’t (get to) assume that
Happy to not be in that community, happy to not have to write (or read) Go these days.
And frankly, most of the time I see people gushing about Go, it's for features that trivially exist in most languages that aren't C, or are entirely subjective like "it's easy" (while ignoring, you know, reality).
reply