22,278 karma · joined November 15, 2017
You can reach me via https://bayindirh.io
It's not only an issue of availability or depending on circumstances you can't control, but a matter of reproducibility hence dependability.
I want to be able to compile critical software when a zombie apocalypse hits, and I have a growing discomfort about trusting outside parties for their availability and benevolence.
Google works like an automatic black-box which tries to deduce your intention from 4-5 words you typed in hastily.
I believe any ordinary user is still pretty happy about Google search in its current iteration. My mom doesn't get a YouTube premium account because she says she likes the ads, for example.
So, from our bubble, Google might be regressing, but the picture might be very different for the majority of Google users.
I remember LG as Goldstar from my Grandma’s microwave oven. That was not something unreliable, but rather unremarkable appliance with no glaring problems. It was eh. Then they became LG.
I remember their other electronics. AC units, phones, TVs, optical storage devices. All of them were either okayish or below that. Phones? Sub-par even if they were innovative. TVs? Unreliable and lower quality than their peers. Optical storage? Can’t read a disc it burned 30 seconds ago, or can’t rip an audio CD correctly, or broke in a year.
I have seen so many LG devices fail or fail to meet their own specs they advertised with in my life, I have sworn to not buy any LG device ~25 years ago.
I somehow had to buy one of their portable DVD burners because I needed something quick. It failed to read a pristine CD other drives read at full blast after taking it out of its box.
So, please tell me I’m delusional. Invalidate my experience I collected over decades. Tell me about my grandeur.
I can tell you how many Samsung devices I have still continue to run or outlived their expected lives in another comment, if you feel like reading it as well.
I’m waiting.
I genuinely miss that era of computing. Simpler, more fun, and with way more but not as crippling problems (except Linux support and WinModem. I'm glad that we're past that).
My own Siemens fridge is with me for ~14 years, as well.
I have replaced shock absorbers and power switch of a 15 year old Beko washing machine last year, and it cost me 6$ plus workmanship to get genuine parts installed in 20 minutes.
I bet that won't be very possible over there, though.
The fridges are dead-silent and working great for 7+ years. Washers are also nice, washing for a bit too long but don't wear the clothes down and have better stain removal performance than their peers, and dishwashers are extremely slow and not designed for European market. Their baskets are not suitable for our dishes, we can't fill them efficiently even.
So, from experience their fridges are A-OK, washers are great with some caveats, but dishwashers are not good.
My first choice is still BSH group and Beko, but Samsung is acceptable if required, but LG? Ain't nobody got time for that.
On the other hand, RPM still doesn't know about reverse dependencies, automatically/manually installed packages, version holds, etc.
Either one is advanced enough to handle a big distribution and have their advantages w.r.t. each other, but I still prefer .deb as a person who works with both. Also, .deb can encode much more information about the software package it contains.
On the other hand, I have been using Kingston Canvas Go SD cards on my Raspberry Pi boards for a fairly long time now, and these cards' random access speed is above and beyond of other, older cards while not being expensive.
Now apt works like it's running on an SSD.
I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.
Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.
Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.
We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.
Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.
...and aptitude. Yes, that TUI thing. It's magnificent.
Now a colleague of mine is handling these. I'm more on the OpenStack & HPC side for other stuff.
I'm in this for a couple of decades now.
We used to run it on our Grid nodes, and while it was not bad, it was not that smooth, either. It was a little kludgy but worked if you didn't diverge from the happy paths much.
Now Debian has Extended Long Time Support via Freexian, I believe CERN has enough confidence to use Debian instead of RH family, and that will make lives of some people way easier. Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
These posts are not only a waste of time, but it also makes me feel deceived and betrayed. Why this is important? Because it's the honest take and bears the load of the reality of the post.
Please, don't make me read something you didn't write.
Disclosure: This post, incl. llm-sounding paragraph is typed by a human. All of the keystrokes are 100% human and made possibe by burning ATPs and firing tiny lightning bolts across some brain cells. No humans are harmed or GPU hours are burned in this comment.
Total water consumption: 50ml of cold spring water, because I'm thirsty.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
Everything is already at the background. That thing doesn’t need a CI, not the classical or AI enabled kind.
Maybe I was not clear about that part of what I do. Three minutes of something not working correctly doesn’t burn our world down.
Practically since eternity, but just as we learnt to manage current rate of "fast" and "breakage", somebody attached a solid booster behind us. So we're trying to understand what happened and what's happening and what will happen.
> I think a lot of the laments about "good" code are really about "ownership"
People owning what they did, have responsibility and initiative about doing better is always a good thing, yes.
> and as someone who spent most of my working career in OTHER peoples code bases I have seen some things.
I can understand that, I'm sorry you had to go through this.
> There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
My codebases are as great as my knowledge. I love when someone reads my code and points where I f'ed up. I also love to show what I did has achieved something I was aiming for and discuss how to achieve it betterer.
> The system is designed to reward heroes who fix problems...
And this is the problem. Because I work silently and diligently build something looking unimpressive while working like an atomic clock without any problems.
I labeled the person who uses AI to generate code and uses their brain and wisdom about the system to refine that code as the luddite since they will work slower when compared to other "higher performers" who don't care about the code quality.
In my framing I'm aware that the person is not a luddite per-se, but will look like it since they will be slower while trying to create better code, albeit using AI in the process as well.
Citing myself:
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
> Ideally you want your luddite fired...
The luddite is the person holding everything together.
Like the office maid who looks like doing nothing but keeping morale high and everybody's sanity intact.
1. Caring about the company when you are a worker and not owner?
Yes and no. I don't care about the company. I do care about what I do. It's a self-respect matter. I do good work not because I'm a slave to company, but because of self respect. My deal is simple: "I'll do my best to produce the best artifact and push the company further as long as it doesn't conflict with my personal principles, you'll buy that time for that amount of money".
I have a simple, foundational rule: I'll sleep sound at night, and this rule is rooted in my ethics. So, I don't shortchange anyone, incl. my employer. If terms change between us, we will discuss, but this probability is not a reason to do shitty work (or optimize for money, or which sugarcoated absurdity others name this).
2. Companies will throw away/layoff people with no notice?
Yes, this is bad. This is life. It's not nice, fair or acceptable, but without unionization, you can't act against this. So, you either try to change this or you just accept it. Realities of work life is not a predicament to shortchange your employer again.
This is as absurd as saying "I'll die anyway, why do all these things? I can just die on-demand".
Meaningless...
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
We can accept that, but you all shall really unionize. It's not scary. Try organizing. It's a force multiplier.
4. Invest emotional and physical labor in ventures you gain completely out of
Everybody should have hobbies either productive or unproductive. I can't find the question.
That's true, but it doesn't have to stay in this form.
> with AI coding IS faster and quality is better than ever before.
Citation needed, because the last study I read about was painting a completely different picture about code quality. Also, just because the AI pulling and remixing code from a known repository with high quality doesn't mean your code will be at the same quality automatically. Passing tests is not enough.
> Ideally you want your luddite fired along with the slop generators.
The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this. AI doesn't know your history and trade-offs. These guys do, and can guide you to clear.
AI can't.
Believing that AI will create bug-free code from start is believing that Rust is the silver bullet.
There are no silver bullets.
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
Try replicating it with a couple of agents. Not the capabilities, but the performance, stability and dependability and sustainability as well.
Same is true for my favorite text editor on macOS, BBEdit, or IDE of choice, Eclipse. I can increase the number of examples.
These tools are valuable not because they are expensive. They are valuable, or indeed priceless, because of the polish they have. The small features make no sense for a beginner or how they cope when things get absurdly haywire.
Immediate features make us excited and they are easier to replicate because they are visible, but things like performance, dependability, error recovery or the small tweaks they have gone through in the last decade are not, and this is what matters.
We're exploring computing via AI again, and we act as that we did nothing in the last 60 years or so. Software and computing is much deeper than it looks at the surface, and we'll learn this in a very very painful way, again.