Hah, maybe Ted Ts'o is a savvier political operator than I took him for. Invoking a seemingly innocuous (to the mainstream) phrase with heavy undercurrents (to a minority) just to trigger their ire and making them seem unreasonable to any outsider is a great strategy if you have as yet been unsuccessful refuting the central arguments for Rust in the kernel on technical grounds.
I don't see it. A lapsed maintainer's description of how, in their own perspective, an adversarial rallying cry is less than compatible with a prominent position in a collaborative setting… may be many things, justified or not.
But a credible threat it isn't. You know this, I know this, and every reader of this message knows this, too.
GPU performance should be somewhere between PS4 and PS4 Pro. More memory is a good sign that Nintendo's machine will allow a larger software catalogue than that of the Xbox Series S, where 10 GB has been a severe impediment to porting.
I'd think that this only means that a model cannot suffer from overfitting on average. So, it might totally have been overfitted on your specific problem.
So what you're implying is that for roles where other companies do have managed to establish functioning remote work protocols, we should interpret RTO mandates as a public display of organizational dysfunction if they were unable to emulate those within the span of, oh, five years?
Also I'm pretty sure employers don't generally pay for, or care about, the commute times of employees…
I think this is probably the best place within these comments to note that one thing some people expect of a configuration format is to be able to hide information from the consuming piece of software.
Normally, it is often useful for a program to receive all the configuration from all sources. ("This flag is normally set to TRUE, has been set to FALSE on this system, has been set to TRUE by the user, and now there's an environment variable that says one thing and a command line flag that says something else.") Sometimes, integrating several incoherent settings into one is dependent on its consumer, or even the setting itself. Sometimes, you would like to be able to debug how different settings interact with one another. Sometimes, different settings can be merged without issue.
CCL exposes everything to the program receiving the config, which is something (some) people seem to abhor. I can see how wanting to hide information can be both useful and detrimental, so I'm wondering if this issue is actually orthogonal to configuration languages, meaning CCL, and others, shouldn't even concern themselves with it.
I think what we are really talking about right now is essentially a pair of jobs that, though both called "software engineer", are vastly different in scope.
One of them is a software developer who basically does just that, implement requirements. To enable an engineering department with this type of developer, management needs to already have developed a pretty good view on the business processes that could benefit from automation, or that could become feasible in the first place through software. It is understood that a 5% improvement on the critical path can be more difficult, yet still more worthwhile than a 50% improvement in some less important part of the system. To gain this understanding, management needs to know what is technically possible and perform lots of requirements analysis. After that, well-defined work packets can be handed down to rank and file engineers, and then everyone is on their merry way.
The other kind of software engineer performs most of this support work on their own. Such an engineer has additional responsibilities, but can be useful in many more places because the surrounding support structures don't need to exist. You might not even have to give them specific guidance. However, it means that to use this kind of engineer effectively, you have to expose them to accidentals like time, money and risk, or they will not be able to accurately assess where their talents would be most useful.
Many organizations will actually have both types of engineers. But invariably, the perception of how valuable they are will be heavily skewed in favor of the latter kind of engineer. In the hands of management, they handle like a chef's knife, while the "pure" type of engineer would feel more like a cookie cutter. Even the sharpest, most efficient and most perfect cookie cutter will have a hard time to be perceived as more valuable than a reliable multi-use tool that needs next to no setup for decent results.
The point is, maybe you really hate all that stuff. Nothing stops you from being an awesome cookie cutter. More power to you. I suspect, however, that most of your colleagues would regard that as a career-limiting move.
This exchange is fascinating to me, because I still feel like we're talking past each other.
I suppose it could be helpful to think of a job designation such as "software engineer" as sort of a shorthand for "businessperson whose toolbox is one of a software engineer" as long as we're in that employer-employee relationship, and if we want to exclude all the pesky business stuff from our daily doing, it cannot be in the context of that relationship.
This also means that all the usual problems of deficient software craftsmanship, such as inconsistencies, accidental complexity, faults, low velocity, and so on, aren't even problems as far as the employer is concerned as long as there is no impact to the business.
In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money. Either you accept the task of deciding what's good or bad for business, or you don't.
Some devs who dislike actually engineering around time, money or risk constraints at work do open source stuff in off hours where that stuff doesn't matter. The one to decide if that's worthwhile to you is yourself. In the context of a business, engineering is simply a requirement to what's actually its goal, which is of course making gobloads of money, consistently, with minimal effort.
One thing that I can see though is that in many of these cases where engineering is asked to work on high-impact issues, engineering doesn't actually have all the information, or the toolset required to draw conclusions from it. In that sense, yes, demanding that from engineers comes across as a bit lazy. Nevertheless, it's not like you have to prove to e.g. Netflix that the service doesn't meet your requirements anymore: the onus is on them, and the same way it's on engineers to prove that their salaries are warranted. Of course, that goes both ways, and your employer can fail to meet your own requirements.
The option to have less agency is one that many employers will gladly grant you, but we are not married to companies, and these arrangements have to make sense for us as individuals as well. Hamstringing ourselves from being able to demonstrate our worth doesn't feel like the correct course of action, even if we care more about our produced engineering artifacts than even its buyer does.
Do you receive financial remuneration for your services as an engineer? Then I'd say you're engaging in an ongoing business transaction. As such, the parties to the contract this is happening under will each evaluate whether continuing the existing business relationship is worthwhile.
You may think that this kind of deliberation is outside of the context of what being an engineer is, but it's certainly not outside of the context of what being an employee is. If you wish to be an engineer and not be saddled with business stuff, don't demand compensation, or only token compensation, which is what I alluded to at the end of my last post. In the context of business, all parties need to constantly prove that what they're providing is worth more than what they're asking for.
You can work at a company that asks for "impact", and be given a degree of agency for determining which problems are worth solving, and solve them, hopefully leading to increased revenue, reduced costs, or reduced risks. Or, you can not do that, do whatever Jira asks you to do next, and have no case as to why the company should give you more money or indeed continue to employ you in favor of another engineer who can demonstrate more of an "impact".
As an engineer — in other words: a salaried employee — you're already a businessperson. How do you negotiate for better total compensation or benefits if you reject knowing, and thus positively influencing, your worth to the company?
If you really don't want to engage in that sort of thing, I'm sure there's a lot of companies that'll let you be a fungible code monkey for pennies…
I understand this is the general policy in a few places, like Germany. The general idea seems to be that it is more beneficial to a society if criminals are given a viable avenue to lead non-criminal lives again, with the alternative being people going "ah fuck it, I guess I'm a criminal now".
I'm surprised at this concept spreading in the US, since the system would generally benefit from having perpetual perpetrators percolating through the prison slavery system.
Exactly. Ideally, we'd all follow the Benzite approach, which is to withhold any and all information from one's peers until a complete analysis has finished, and the best possible remedy to the problem has already been applied. Because how can a miscreant use a vulnerability if it hasn't even been published yet?
As contributors, we enjoy a lot of trust, as we should. That's why it's not a problem if we make seemingly random changes that don't necessarily make a lot of sense, but seem relevant to security, when they actually fix an issue in the code. After all, it's necessary to prevent bad guys from gaining sensitive information, and to keep your colleagues from being unduly bothered with challenges they could possibly help with.
In my younger years, I used to employ the Y combinator as a way to avoid naming recursive functions because I didn't want to necessarily dignify single-use code by abstracting it into a named function that I'd never call anywhere else. Instead of calling itself in the non-base case, the anonymous lambda simply calls a first-class function passed into it, with the necessary plumbing abstracted into the generic combinator.
Fixed-point combinators can be made to work with tail recursion, so I don't think tail recursion forces anyone to name anything. Certainly, how easy it is to go with this particular approach depends a lot on the semantics of your chosen (or imposed) programming language.
Maybe I'm misinterpreting something, but… isn't this really about https://en.wikipedia.org/wiki/Perfect_hash_function? "Perfect" doesn't represent a statement of quality here, if that's what you're alluding to.
Your computer does not have a problem with non-existing LBAs. The SSD controller might not like missing raw flash addresses, but that's abstracted away from the user perspective anyway, even if for no other reason than the FTL.