crabbone

I didn't mean to say it was illegal, I meant to say it was an advantage in competition against the open-source counterparts because those usually cannot afford to make discounts of any kind.

More concretely, Microsoft used to claim that the price of their software is compensated for by the operational costs (which is false, but they managed to convince a lot of people).

In the same way, due to having deep pockets, Microsoft can, temporarily, operate at a loss only to out-survive the competition only to crank up the price to the ceiling once the competition is gone.

I'm sure this is a serious problem, but I'm not sure it's the main problem. The other one, that might be an even bigger problem is the way Microsoft sells its products. While, technically, most of the stuff they sell appears as B2C products, they are sold as B2B, and increasingly more so since the emphasis shifted towards the Web versions.

What this means for the users is that their interests are overpowered by the interests of the organization supplying them with the software. An organization can be more easily bribed both "legally" by offering a (temporary) discount and straight-up illegally by paying the procurement officer. Microsoft is known to do both. This is not a battle one can win on technological merit alone, unfortunately...

To comment on my concrete (and quite miserable) situation, here's how it went (and does, even worse with the advent of AI, to this day):

* A report comes from the field (to the support team) that something is broken (or highly desired by the customer).

* The support team assigns the ticket to the lead engineer.

* The lead engineer writes the code and after a quick battle with CI pushes it all the way to the customer in need.

* Since it's the lead engineer, he has the authority to merge PRs w/o consulting anyone, which is what he does. You just pull the changes and marvel at them, or at the sunrise, whichever you like best. The "urgency" is used as a justification to skip the due process.

Now, when AI came into play, two horrible things were added into the mix:

* AI audit and code review. The audit is a 50/50 chance between finding a real problem vs misunderstanding of the purpose of the code or the context in which it is executed. The AI will also come up with a solution that is either completely wrong, unnecessary or touching too many things for a human to track. Code review acts in a similar way, except, technically it fills the role of a human reviewing the code, so it gives a sense of false security to anyone making changes.

* AI generating code that is hard for humans to follow. First and most obvious problem is the volume. In minutes AI generates changes that will take months of effort to review. But this is only the beginning of the problem. When reading code written by humans, another human builds a model of the author's approach, ability, intention and permissions. When it comes to AI, these... let's call them "dimensions" are all over the place. The generated code you read may seem very plausible for a while until you stumble into a crucial functionality that completely invalidates everything you've learned about the change so far. The change may make unnecessary segues into the territory it was never meant to touch.

So, even when there are code reviews, they now miss a lot more than they used to when only humans were writing code.

Also, and this is a pathologically bad, but a very common practice: the reviewer's name is missing from the record. You run git-blame and only see the author, not the reviewer. When things go down, the author takes the heat and the reviewer is nowhere to be found. Subsequently, reviewers don't feel like they need to care as much about the outcomes.

Oh, and one more thing. To be effective at reviewing anything you'd want to try things... as in to test them. Perhaps come up with some idea about what things must happen and what things absolutely must not. But where do you find those? Usually... in a design document, s.a. a PRD, but in the case where that design (allegedly) was solely in the head of the person writing the code, how do you even know if the behavior you conjecture the code has (because there are no tests) is the desired one?

Well, I had to be more specific instead of trying to be dramatic...

The thing is, nothing in the suggested procedure addresses the problem of how you are supposed to distinguish the decisions that matter from those that don't. Whoever came up with this idea must've thought that it's trivial to the point it doesn't need solving, but it's the opposite, unfortunately.

Also, FYO, linters aren't responsible for code formatting. It's the formatter's role. Linters advise on style. I.e. the problem of bracket placement is not solved by using linters, an example of problem that is solved by linters is the maximum number of properties a class is allowed to have.

But the meetings about formatting or using / disabling linter rules still happen. Having tools to do that didn't make the problem go away. What did happen, however, is something more like natural selection. The increased volume of newcomers which the field saw up until maybe five or so years ago were mostly steered in a particular "winning" direction. So, today, naturally, you have most people agree on a set of rules to follow because the majority came from the same background. You need a bunch of old-cadgers to work together on a project for there to be a feud over styling rules.

This is what usually happens if you let incompetent people make design decision: they stay with the first and worst version forever.

Right now I'm in the process of leaving a company where this happened over and over again. The company's product and design aspects were always neglected in this specific way: whenever a problem was discovered its solution was assigned to whoever would write the code to solve it. That's it. The QA would be notified a week or two before the release and after the solution was "finished". The QA would then not be allowed to even comment on the overall design, only the superficial bug reports were allowed to go through.

Needless to say the product's code-base is a dumpster. The morale is low because it's a daunting task to deal with this dumpster on a daily basis. Now, even if you wanted to, you wouldn't have a budget to fix the previous design mistakes because of the layers of more mistakes that were added on top of them due to the low morale and lack of budget / lack of procedure for making better design decisions. The only thing that keeps the product afloat is its uniqueness in a rather niche field and the backing of a large company that acquired it, but doesn't really depend on it and has no time for a thorough audit.

Parent doesn't have experience of working with codebases with slightly high than average code quality requirements.

In products s.a. storage, avionics, medical appliances etc. it's very typical to have a requirement for each commit to compile and to apply tests retroactively. I.e. once a test is added against an existing feature, it is run against every commit since the feature creation (this is also why git-bisect exists).

However, it's true that a lot of companies would probably do better with just rsync instead of Git. Their Git history is in such a bad state that it's basically useless. It just doesn't make sense to use such a complicated tool as Git to deal with the average workflow.

In terms of UI for Git, I've never seen anything getting remotely close to Magit. It's both in-depth and a simplified stateful interface.

Here's what I mean by "stateful": one of the huge problems with command-line tools is that their output becomes mostly inaccessible upon subsequent invocations. Suppose you ran git-log, and now you want to apply the knowledge gained from reading its output to your next action (say, you want to cherry-pick a commit). But you are lucky if the hash of the commit in question is still somewhere in the terminal. Otherwise... you aren't writing that from memory...

Stateful UI to command-line tools allows multiple interactions in parallel and preservation of information obtained in previous interactions.

Git needs a lot of state. You need to remember facts s.a. what branch you are on, what branch did you switch from, what files have been modified, what commits haven't been pushed etc. The requirement to remember all of this is overwhelming and makes the effective use of the tool difficult. This is where various tools come to help (eg. Shell plug-ins that provide auto-completion or modify the prompt to incorporate some of that state info).

I believe that people complaining about difficulties of using Git are often handicapped in their use of surrounding tools that would otherwise mitigate the problems above: they don't know how to add Shell plug-ins that display the current branch, they don't know how to have multiple tabs/panes open in a single terminal session, how to copy text between those tabs/panes, they don't know how to invoke / search auto-complete options.

Genuinely, if you don't have tools to help you use Git, something that people who are used to navigating the world of terminal UI, using Git becomes very unpleasant.

It might be uncalled for, but let me use a philosophical reference: you are trying to derive ought from is. Many tried to prove it to be possible, but most face such propositions with skepticism.

Let me give you some examples of things that were absolutely detrimental to the business of a large company that vanished in a matter of years if not months:

* Adobe Flash. Flash players was for a few years the most installed program on Earth. It vanished without a trace, dropped like a hot potato by everyone who swore they will use it for ever and ever.

* ASP Classic, especially in combination with VBScript. It was the hottest thing twenty (or am I getting too old?) years ago. Everyone was selling books and courses on ASP Classic, probably half the Internet was written in it... and it's gone.

* I expect x86 ISA to eventually die and be completely replaced by ARM or maybe something else. Some big players are already jumping off the bandwagon, and it looks like things are only going to get worse.

There were, of course, more, but I think these three examples should suffice. If tomorrow Google comes up with a better format, or, for whatever reason, tanks its business, or decides to switch to vertical farming in Arizona... say goodby to Protobuf. They owe you zilch. They never promised you anything. You were allowed to use their tech because it was convenient to them, but once it's not, you will be holding the bag.

This is the difference between a standard and a spec published by the designer. The designer is free to make any changes they see fit, up to and including completely destroying their work. They can pull the run from under you making the users pay for the use, they can make modifications to their tools that will require from you to buy things you wouldn't normally want to buy. The possibilities are endless.

It's like in that meme: it's not enough to say it, you need to declare it.

Or, in other words, what makes a standard a standard is that you declare that it is a standard. This declaration carries with it an obligation to respect the standard for ever and ever (like C89), regardless of whether in retrospect you realize you've made mistakes and want to fix them, or maybe wanting to add more stuff etc.

Having a standard is restrictive and uncomfortable for the designers, that's why many opt not to have a standard. Eg. Rust language doesn't have a standard (even though you may, of course, find documents detailing how it works), same for Python, Java and many other popular languages.

I don't know where you get the confidence... When it comes to Protobuf, we are now at version 3 of the format. It's been around for a while, but I'm old enough to have implemented v2 parser myself... v2 is partially supported in v3, even though the support isn't documented. But, emphasis on partially. Some things are no longer there.

So... I'd say that your faith is unfounded. And, in general, there's no reason to believe that a commercial entity will commit to supporting any particular technology if that doesn't generate them a profit. Standard is better.

Why does it matter for some Python implementation if the Google C++ implementation has a lazy or eager parser?

I wrote about it in my repository, but I'll try to summarize it here: Protobuf is full of bad ideas. One such bad idea is that message fields are allowed to repeat and that the last field wins. So, if you were to write a SAX parser, you'd have a dilemma with how to handle this bizarre idea: do you accept that a callback for some property might be triggered multiple times or do you read the whole message ahead of time and then call callbacks exactly once for each property? If we accept that the parser must be lazy, we "solve" this problem by allowing the parser to read ahead (it needs to do this anyways), but this is a wasteful way to parse (uses more memory than necessary).

The important part of protobuf is the spec of the wire format. That is what makes the standard an interop format.

I'm not sure what are you trying to say here. All messaging formats are made up of... wire format, that's what they are for. Maybe I'm not seeing it?

Personally I also prefer code generation over dynamic parsers and generators.

I think you are trying to say that you prefer source code generation over generating supporting definitions at runtime? I wasn't talking about dynamic parser generation (eg. Lark). In my case, the parser was hand-written (using Bison + Flex) and compiled ahead of time, but the Python definitions supporting the Protobuf IML were generated at runtime.

If my guess is true, I'd like to hear your arguments in favor of generating Python source code that translates Protobuf IML into Python. To me it looks like a waste of space on disk... I really can't think of any reason to want that.

I don't know what your metric for reliability is... but I would say that the messaging / serialization format can hardly be blamed for reliability problems s.a. service uptime or service responsiveness etc. Such problems usually arise at a level where details like the choice of messaging format are not important.

Messaging format may affect application performance though. It would affect metrics s.a. throughput or bandwidth.

In a way that is more difficult to measure, a messaging format can affect the number of bugs created by developer using it and indirectly the delivery times. But this can be mitigated by tooling (i.e. Protobuf isn't self-documenting, so if you don't have the schema files, you can't interpret the messages, but you can write a tool that you can feed the schema definitions and then use the tool to interpret the messages).

It's one of the few things Google _hasn't_ deprecated

You might be unaware of it, but there were Protobuf v1, v2, and now we are at v3. Even though it's not documented, v3 supports most of v2, but not all of it (I think v1 was never used outside of Google itself). Google never properly released Protobuf, so, they can't really deprecate it. Even their formal grammar is full of errors.

Hey. I wrote another Python implementation of Protobuf. (protopy https://gitlab.com/doodles-archive/protopy it was a while ago and haven't touched it since). I'm not saying it's better than whatever this is or that it's any good, I just post it as a proof of sorts that I'm familiar with the problem.

So, without further ado: Protobuf isn't a standard. You can't have a non-standard implementation of something that doesn't have a standard to begin with. In reality, you have Google's implementation for C++ and then everything else. Everything else was, for the most part, not written by Google. And it doesn't always align 100% with the C++ Google's stuff.

Furthermore, C++ implementation has a lot of idiosyncrasies specific to that language that can't be translated one-to-one into other languages, or, in some cases, shouldn't be, even if they could (eg. C++ implementation is all about source code generation because generating runtime entities s.a. classes in C++ is very difficult, while in languages like Python, generating classes at runtime is easy.)

Furthermore, C++ implementation has a specific way of parsing the binary payload (lazy: only the top definitions are parsed, the inner structure of messages is parsed on-demand). But, is this how every parser should behave? What if you want a SAX-like parser?

----

In the hindsight, I just think that Protobuf is not a good format for writing reliable software that aims for decades of usage. We, as in the whole programming world, don't have good formats in general, and whenever we come to the point of having to use some, we either go with an existing popular but crooked or roll our own, probably also crooked. The standard you alluded to would've been great (perhaps a refinement of ASN with more attention to parser implementation, more concrete versions etc.?) But we aren't there yet, and there isn't even a work group to try and address the issue.

I think you are putting the cart before the horse: the code was written intentionally, i.e. someone first had a thought, and then fleshed it out in the code (and maybe had forgotten all about it the minute later).

When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them).

Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.

My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.

The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).

Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.

Oh, I've worked in more than a dozen of software companies. When it comes to planning activities and setting goals, I've rarely seen a lot of sense.

I mean, we are in the industry where it used to be a standard practice, not so long ago, to deliver daily reports about one's activities while "planking", or throwing a beach ball to another person doing some silly acrobatics...

It should come as no surprise that there's no rigorous assessment protocol for these kinds of things anywhere. Retrospectively, I will admit, that enormous amount of effort and resources are wasted due to bad planning. But it's still not done.

I can imagine that with the field becoming more competitive, eventually, the industry specialists will come together and try to address the problem, but so far and for so long the resources just kept flowing in, the huge waste wasn't really a problem.

A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way.

When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary.

LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.

Not the author, but as someone who frequently has to answer this question, I'll chip in:

A mistake is a mistake, whether you have a way to reproduce it right now or not. It's pretty much a given that whatever means you have right now to reproduce the problem will evolve and broaden the scope. Also, if you haven't found a way to reproduce the problem, it doesn't mean it doesn't exist: it takes a lot more effort to prove that it's impossible to reproduce than to simply not being able to reproduce the problem.

Here's about the Israeli PM, and why he's allowed not to wear a tie:

One day, Netanyahu shows up to the Knesset not wearing a tie. The speaker then reminds him about the decorum, to which Netanyahu replies that the queen of England allowed him not to wear one. The speaker then inquires about the circumstances, to which Netanyahu replies that he didn't wear a tie to Buckingham either, and that the queen told him "perhaps back in Israel, you might not wear a tie, but you must remember to wear one here."

In other words, Netanyahu is, by no means an example of what anyone would consider to be "classy". He's not the worst example, but he certainly fits the stereotype of obnoxious, loud, poorly dressed and otherwise poorly mannered.

No, I don't think so, why would it?

Absolutely. It's kind of ridiculous to watch a typical Israeli recruit struggle with it. There's a practical reason for it: you have to speak clearly when you are on comms, and nobody can you see swing your hands to explain yourself. But, military being military, this is just a rule that's applied to everyone. Another reason is that you have to stand at attention ("amod be dom matuakh") when you are talking to an officer. Again, this applies to basic training ("tironut") only, since during your regular service you rarely stand at attention in general, let alone when talking to an officer.

Well, I lived in Petakh Tikva and met some people who lived there before 1948. There are still some patches of land (eg. behind Belinson) that used to be in Turkish possession, then were bought by Keren Kayemet le-Israel, and then kinda went nowhere. That one looks like it used to be an... orange orchard (is it what it's called? the orange tree plantation?). Anyways, growing oranges was a very common agricultural activity in that general area. Not really done by the nomads. There's also a park, if you go from Ramat Gan around Bney Brak in the direction of Petakh Tikva, and it has an old mill that used to belong to some Arab family (that whole place used to be an Arab village before 1948). Now it's a museum of sorts.

Petakh Tikva is also commonly called "Em ha-Moshavot" (mother of settlements) because it was one of the first, if not the first settlement by Jewish immigrants. It was very much the pilot in terms of how Jews were trying to get a hold of any plot of land they could and entrench there, including the tactics I described earlier. Of course, this wasn't the only tactics, and it wasn't necessary hostile to the locals. Another tactics that is well-known around that time is called "homah u-migdal" (wall and tower), which refers to the fact that having a wall and a tower was a necessary prerequisite for a place to be considered a settlement (for the purpose of drawing maps), and so Jews, esp. the Solel-Boneh (a well-known today construction company) would invest into building these sorts of "settlements" to claim more territory.

I'm not saying that the expulsion of Arab fellakhin from their peasant jobs was the reason for the confrontation. But it certainly contributed. And it certainly happened. While even to this day there are nomadic tribes in Israel and the occupied territories, none of them are Arabic (they are Bedouin). There are plenty of Arabic agricultural communities, and many of them can be traced back more than a hundred years. For instance, the Jaffa Oranges you might associate today with Israel (they are a popular export good and found in a lot of Western supermarkets) were actually bread by Arab farmers living around Jaffa (south of modern day Tel Aviv).

jobs programs and helicopter money where people get paid to do nothing to keep the economy humming.

The article addresses your concerns already. I know it's long, but you could probably skip a few paragraphs in the middle and start here:

Piketty, no conservative, has argued that UBI fails to address root structural problems: “unequal access to education and health, low-paying and low-productivity jobs, malfunctioning markets, corruption, and regressive tax systems.” David Shor’s polling data bears this out from the other direction: UBI is unpopular with American voters; a federal jobs guarantee has legs. People don’t want a check. They want work. They want purpose.

But this doesn't summarize the argument, it's just where you need to start reading.

If I try to summarize the argument, it says that jobs are a bargaining chip in the hands of laborers (the largest fraction of our society). Currently, they use it to secure certain freedoms and benefits. If, however, they no longer have jobs, whoever gets the role of distributor of the wealth produced by the AI will not be compelled to distribute it fairly... well, the whole concept of fairness will have to be reinvented (because, roughly, now we base fairness on individual's contribution, but that's not going to work anymore). But, most likely, it will lead to a dictatorship of those with access to AI over those who have none.

* * *

Here's my (unrelated to the article) historical parallel. In the beginning of the 20th century when Jews started campaigning for bringing more Jews into Turkish, then British Palestine, the process often went like this: Jewish community or a wealthy individual buys a plot of land from a Turk owner. Turks never worked that land themselves, and used to hire local Arabs to do the agricultural labor. Jews would not rehire Arabs after acquisition, instead, they used the newly bought land to create jobs for more Jewish immigrants.

This greatly contributed to the animosity between Jews and Arabs in Palestine because even though initially Arabs would be paid off to "go someplace else" after the land purchase, realistically, there was no other place for them to go to. Which led to spreading poverty, which led to sporadic attacks on new land owners. Which led to retaliation... and well, the conflict never really went away, didn't it?

This just might happen on a much larger scale in countries like the US, if suddenly a large fraction of population finds itself powerless and being unable to influence the decisions of the government.

I'm sorry... you didn't understand the article.

The goal of having a job isn't happiness. At least not immediately. The goal is to have something to bargain with: employees offer labor, employers buy it. If employees don't deliver, they get fired, if employers don't deliver, employees leave / strike. This is what keeps system in a semblance of balance. But once would-be employees can be employees no more, they have no way of influencing any aspect of their governance. Not economical, not political, not military, not ethical.

In other words, people need jobs to try to secure their place in the world on multiple levels. It's not about socializing at work, at least, that factor is absolutely not a priority.

Well, it's the same problem with all sorts of free-market capitalism and derivatives. They all believe there's infinite "somewhere else" that resources can come from, or the customers, or the funding etc. But reality is very much finite. And so instead of the theoretical equilibrium we get monopolies and collusion to manipulate markets.

The article, actually, addresses your claims:

The optimists will tell you this is just productivity gains. The economy has absorbed automation before; agricultural employment collapsed from ninety percent of the American workforce to two percent and civilization continued. David Autor at MIT has shown that roughly sixty percent of today’s jobs didn’t exist in 1940. New technologies create new categories of work. True. But there’s a difference between an observation about the past and a law of nature, and the optimists consistently confuse the two. The agricultural transition took a hundred and forty years. Carl Benedikt Frey at Oxford has documented that the Industrial Revolution took seventy years before wages and employment recovered for the workers it displaced. In the interim, wages stagnated, the labor share of income collapsed, profits surged, inequality skyrocketed, and the political consequences included the Chartist movement and widespread social upheaval. As Frey puts it: “Most economists will acknowledge that technological progress can cause some adjustment problems in the short run. What is rarely noted is that the short run can be a lifetime.”

So, the author believes that the problem with your reasoning that it will take a long time for the niches you are talking about to be filled (lifetime, maybe more), meanwhile things will look quite bad for most those involved.

I am even less optimistic than the author. The new aspect of this workforce displacement is the centralization. Of course, previous advances in automation also caused a degree of centralization, but AI is posed to become super-centralized if you will. There will be just a handful of suppliers and nobody will be able to challenge them, similar to situation we have with microprocessors today. Needless to say this is absolutely not a healthy situation for the world's economy.

Well, where I work, "automation" is part of my job title. And if I ever even suggest that I've done some work outside of the tasks assigned to me that has something to do with my job, I'd be sent into disciplinary hearing. Any work I do for the company must be sanctioned by my boss, otherwise it's treated as dereliction of duty (under the pretext, that I should've been using that time to work on my tasks given me by my boss, or, if I had no such tasks, I should've informed my boss about the situation).

And, in my specific case, my boss is not very good at programming, and doesn't like anything I do on that count. So, anything I've done so far was mired in pointless PR reviews and discussions, stalled for many months or simply never made it after more than a year of PRs waiting. Ironically, my boss had to order the cancellation of some CI tests because he didn't accept my PR fixing those tests. And it's been like that for something like three years now.

I wish this situation was exceptional, but it happened more than once, and, by far, I'm not the only one experiencing this. That's what I mean by "initiative is punishable."

It was drilled into me since childhood that speaking with your hands is lacking "class". On a conscious level, I know not to judge people by something as superficial, but on subconscious level, if someone is swinging their hands in the air while talking to me: I don't want to talk to them. It's the same with being loud, or using stop words etc.

I haven't been to Italy, but this was a huge deal for me living in Israel. In Israel, it's a substantial cultural divide between descendants of Arab countries refugees and those coming from Europe. It's generally seen as "proper" to not use your hands. In the military, especially in basic training, that would probably send you doing pushups.

I live in the Netherlands for about five years now. To be honest, I didn't notice people talking with their hands... well, outside of the Middle East or North African immigrants. Also, I don't really have Dutch friends to the point that we'd spend enough time together for me to notice how and if they use their hands during a conversation. In more formal context, I don't see the Dutch doing that.

I absolutely don't see these as benefits... Living in the Netherlands, apartments owners typically have to pay "VVE" (service fee for the ongoing upkeep of the building where your apartment is), while house owners typically pay out of their pocket for any repairs they have to do.

This was my first time living in a house as opposed to an apartment. It's been three years of bitter regret, and I'm very eager to sell the damn thing and leave the nightmare behind. In the last three years, I had to re-paint the roof, replace the garden fence and a bunch of related stuff in the garden, replace the water boiler. I had to climb on the roof of the house to rake the leaves at least twice a year (not expensive, just scary). I had to repaint areas of the house because the previous owner did a crappy job painting them.

But, most importantly, it's a piece of junk. It's a typical front brick wall with the rest of the house made of wood covered in dry wall. Its foundation is going to skew and sink because... that's the general condition of everything in the Netherlands: the ground water is too close to the surface, so the foundation is too shallow. I can't hang anything heavy on the wall because the wall can't support it. Every wall is crooked and bent and so is the ceiling, so, for example, it's not possible to put a curtain railing on the ceiling...

Everything is made of perishable materials which will last five to ten years tops, and then everything needs to be torn down and redone. Looking at how my neighbors are spending their lives on the hamster wheel of infinite repairs... I want absolutely none of this. Some people enjoy sinking their time and finances into this black hole, but I'd rather just buy hard drugs for the same price all the way until I die. It's just an arduous and unrewarding toil.

I think sleep serves multiple functions. For example, anyone who works out in any-what systematic way knows that sleep is essential for muscle grow. You can't skip on sleep if you want to get fitter. And this probably has very little to do with the more sophisticated functionality of the brain, rather it allows for some process in muscle tissue to happen.

So, whether the LLM "dies" in any sense may or may not be important for what "sleep" is defined to be in this article. It's quite possible that sleep also affects endocrine system in animals or hormones etc... and that's what's causing death, not necessarily anything to do with how brain functions.

I can see very naive points here:

* "Corporate hackers" is a... not a very common thing. In the corporate world most programmers do what they are told to do and nothing more. Initiative is punishable.

* API wrappers aren't actually good. Not to mention that the API itself is very poor. JIRA has a tradition of arbitrary changing things, especially removing things, or not exposing the useful functionality. It's not a well-designed or well-executed product.

* AI is too immature and too non-deterministic to be useful for most of the things you want from a bug tracker. Also, for most companies, it's going to be too expensive to do it this way.

* QA is usually an afterthought, unless... we are talking about budget cuts and cutting corners, then it's left, right and center. Most companies see QA as a liability. They don't see it as producing value. They just have to pretend to have QA so that they can tell their customer they have it. When it comes to making QA do meaningful things, that require hiring good engineers, allocating development time, allocating compute resources... well, good luck with all that! Most QA I've seen, especially in international huge corporations was all for show, to produce appearance of work while following the same, mostly useless and mostly manual process.

I had a bunch of ideas about how QA can be made more efficient, both in terms of resource use and in terms of problem space it tries to address. Doing things like RCA automation or exploratory dynamic* testing... and after trying to see if any of such ideas would have any luck of becoming an actual successful product, I realized that nobody wants to improve QA. If a product made the "certification" (the ability to claim to have tested the product) cheaper, then it could be viable... but this is neither the direction I wanted to go, nor is it really all that feasible to improve a bug tracker in this direction.

----

* What I mean by exploratory testing is a sort of "fuzzing", however one that's more structured. Fuzzing, typically, is applied to the input, which then tries to explore all possible ways through the program under test. Exploratory testing is a test made up of modules that can be combined to produce longer tests. This addresses the problem of difficult to reach "corner" cases in the program, also the problem of reaching code paths that aren't directly (or at all) dependent on input.

While NaCL and Silverlight were both alternatives to Flash...

All these people in comments beating their chests about how WebAssembly is totally good for everything you can imagine, and there's not a single browser game that is not a tic-tac-toe level.

That Just Won't Happen.

Please, read what you quoted to the end. The answer is right there.

Anyways. Here are examples to the contrary: cars and driving. Somehow, collectively, we realized that driving requires learning the tools to a minimal proficiency level. This doesn't prevent anyone from driving a car w/o a license (a document certifying one's learned the tools), but it puts the blame for a certain category of accidents on the driver, thus making it unnecessary to demand absolute road safety from car manufacturers.

What if we treated computers more like cars? Perhaps, in a situation like this, products s.a. VSCode wouldn't even exist in the same way how there aren't cars that don't come equipped with safety belts?

Right now, parent suggests, metaphorically, to equip cars with a system that plans the route in advance, has a required number of passengers for each planned trip and won't even open the doors unless the car reaches its destination. This is what "explicit permission system" is to a computer user lucky enough to have avoided most of the MS / Google / Apple and Co products.