> Authorities believe the at-large criminals snuck up behind the cameras with spray foam canisters and sprayed the lenses before the cameras had a chance to ID them.
> At least 69 police officials have been accused, charged with or convicted of misusing Flock’s system or other license-plate readers for unauthorized purposes, The Post has found, and in at least 15 of these cases, someone outside of the police department — including victims, activists and journalists — first identified the potential misuse.
> Records and interviews show that departments across the country do not regularly audit their officers’ Flock use, a practice recommended by the company, and some law enforcement agencies have no formal training programs or written policies describing how the technology should be used.
How do you know they weren't faulty? Blip flips are usually silent unless you have ECC memory or are actively testing for faulty cells.
Somewhat recently, Firefox implemented memory testing in their crash reporter and found 10% of reports were due to bit-flips[0].
If it weren't for reading that HN thread, I would never have being prompted to check and find the faulty memory in my laptop. It would have gone undetected and continued to corrupt whatever was stored in the affected cells. I did run memtest86 not long after I bought the laptop, so sometime between running that first memtest86 and the 12 months after, it developed the fault.
Non-ECC memory sometimes fails and there's a good chance you'll never know.
Sqlite3 is present in the default installation of most Linux distributions. It has proven itself from years of battle testing in many different environments. To use DuckDB or LevelDB would probably require pulling in an additional dependency.
I would much rather that they had used an existing database file format. Sqlite3 is robust and already present in the default installation of most Linux distributions. Querying system logs with SQL would be cool and likely faster than using the sd_journal API with all it's weird quirks.
If you want to store logs in a database, just use standard rsyslog. It has supported database backends pretty much since its inception at the dawn of the century. No need to reinvent anything.
Well I think we found the reason for journald's complexity right there, systemd devs and reinventing the wheel (plus breaking backwards compat in the process) is a match made in heaven
Text or text-like (e.g. text content with simple control char delimiters for metadata) would be far superior than the slow-down from Sqlite's safety mechanisms. Optimising logs for read, at the expense of write, is a bad pattern to me.
> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.
Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a licence that can be revoked at any time. Additionally, legislation could be written to require such licensed individuals in safety critical roles.
I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a licence.
If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.
The problem with making programming a regulated profession is who gets to define the regulations. You are probably imagining that it would be expert developers with a track record of success. I would bet on it being the people who write lots of blog posts and books about programming and give lots of conference keynotes - whether or not those people have any evidence base to support their advocated policies or any personal track record of delivering good software.
> You are probably imagining that it would be expert developers with a track record of success.
I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.
> who write lots of blog posts and books about programming and give lots of conference keynotes
I do not think people who write blog posts and give conference keynotes should be awarded with roles that regulate the profession because they write blog posts and give keynotes. I would hope that any regulation is evidence driven.
> I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.
Licensing organizations disproportionately attract people who enjoy "administrating" over "doing."
Aviation comes to mind. Most aviation regulations exist because people died.
It's hardly a perfect system, but the problem is mostly that it's too conservative and risk aware, making it difficult to impossible to innovate and ignoring the risk this creates. (The world's most popular light aircraft is the 1950s-vintage Cessna 172, mostly because it's impossibly slow and costly to get a reasonably priced modern competitor certified.)
What you have to remember is that the people who decide who to appoint into these roles are another step removed from the problem domain. They will have no programming experience, or the ability to evaluate programming experience. They will try and rely on metrics or some "data-driven" approach to deciding who to appoint.
What kind of data will they look towards? Here, we have a precedent from frantically points to absolutely everywhere around us. So the people with "engagement" and "reputation", i.e. they gushed on their blog and farmed engagement, will be exactly who gets appointed to make the decisions.
The important part of the professional certification like PE or MD is the liability that comes with it, which means that the professional has a lot more agency. A construction firm or hospital can't really force their professionals to do anything because the consequence is criminal prosecution (and a lot of legal liability for the employer).
Bring a software engineer into a courtroom as an expert witness, and the jury's eyes will glaze over. Bring in the PE who told their firm not to cut that corner, and the hammer comes down hard.
Even if the certification for software engineers starts as barebones as knowing what WASP is, it still provides an avenue for the feedback mechanism to work (the rules "written in blood"), so that the entire industry can study and learn from what happened, instead of this mess we have now, the peak of which is postmortem blog posts. Even now we have plenty of examples of regulatory frameworks where the regulations adapt to the field like the FDA where you've got a huge spectrum ranging from diagnostics to medical devices of which where are many classes, and drugs where every clinical trial can be tailored to the exact nature of the disease.
I have been a professional software developer for decades and worked in several roles where quality and security were at a premium but I have no idea what you mean by WASP. And yet you described it as "barebones" - an interesting illustration of the problem here. Real engineers have many years seeing the hard way what actually works. In software we don't have that kind of consistency and shared understanding of how to reliably get good results yet.
In my experience, good software engineers are often better "engineers" than those working in more physical disciplines, because they get a lot more practice. But traditional engineers have a far better culture when it comes to testing and validation. Since the cycle time is longer, and the cost of mistakes is higher, analysis and testing are generally baked in from the beginning. In software, it's easier to skip that stuff. But software engineers who do get indoctrinated into that culture learn most of the same lessons that traditional engineers do (i.e. how can a component be tested and maintained? what makes for a good design?) and the speed of development means they get more exposure to those types of challenges in general.
In my experience this works both ways too. Good engineers working on physical projects have picked up on some of the useful practices that good software developers have adopted for maintaining progress in the face of ambiguous requirements until they can be clarified and allowing as much flexibility as possible without necessarily compromising quality in the meantime. I believe these relationships can be summarised as something like "Good people keep open minds and learn from what has worked well for others".
The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?
In physical engineering disciplines there are often clearly evident problems if something was built without being adequately specified by the responsible engineers. In a disastrous case a bridge might literally fall down but you're also going to see that a bridge wasn't designed properly if it's distorting in ways it shouldn't under loads that it should be able to support. There are lots of experienced engineers who have proven records specifying buildings or planes or ships that need to not break using established and peer reviewed techniques.
In software we can all agree catastrophic failures that result in loss of life or half the Internet going down are obviously bad. For something controlling a life-saving medical device or the launch authorisation system for the nuclear missiles we can probably all agree that the answer to what quality level we want in the software is "the best quality we can achieve". But those systems have unusually serious consequences if anything ever goes wrong and probably also very high development budgets that can justify such an extreme position on quality. In general we don't have clearly defined levels of software where different trade-offs between cost and risks and other factors might be considered reasonable and acceptable. Nor do we have well tested and universally accepted standards for how to reliably achieve a specified quality level.
> The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?
There is zero useful evidence because there is no one to collect it.
The Institution of Civil Engineers was founded in 1818, after decades of random civil engineering societies in Britain doing the exact same thing we are now (running around like chickens with their heads cut off). It wasn't until after the ICE's Royal Charter a decade later that civil engineering began to get really systematized into the "real engineering" we know today and that charter effectively established them as a regulatory body that allowed that to happen.
There is zero useful evidence because there is no one to collect it.
I'm not sure that is entirely true. There have certainly been a few people who have attempted to study what did or didn't work in industrial settings - either pure academics or people working in industrial research labs. But I agree that currently we have nowhere near enough data to form robust conclusions about almost anything in this field and I think this is the strongest argument that the industry is not ready for any kind of licensing and regulation regime.
Once I was talking about a video game and mentioned a global variable holding a reference to the player character and got the eyes wide open horrified look.
Competence is tangential. They're happy to allow the idiots, so long as they aren't so stupid it makes the organization or the government look bad.
The way licensing fundamentally works is industry basically strikes a bargain with government to it's benefit. Government lets the licensing organization run a supply cartel and collect protection money (dues, test fees, whatever) so long as they promise to enforce (low) minimum standards along the way. Government gives licensees favorable treatment in court (statutory limits to liability, licensed professionals opinions are more equal than average peasants, etc, etc), etc. And all this stands so long as they do whatever the government's rules say (to the detriment of the customers). And of course the professionals make money hand over fist (or at least more than they're worth) in the process because the licensing organization constrains supply.
Society gets just enough scraps to provide the political will to get it done and keep it rolling (the low minimum standards).
...or you wind up with people that know the same answers to the same questions; great for a job repeatedly answering the same questions, pointless for jobs requiring original approaches, beyond a certain point. In law, you'd better know the law... but there are so many ways to work in tech, many with no appropriate titles, many pockets of it which would not survive a certification path.
It's probably worth distinguishing software engineering from the ability to program. Programming is a skill that is similar to reading and writing in that it's a type of literacy, and it shares a common theme with literacy in that even though most of us can read and write, not everyone is good at it. Professions that leverage that unit of literacy build on top of it, and take literacy as a given.
For instance, a lawyer spends most of their time reading and writing, but no one would ever say "you can read and write? Have a crack on our legal team". It's a particular type of writing, and the writing is really a means to an end. This is a distinction that is lost in software development. Every engineering discipline now learns programming, but the ability to write code shouldn't be a license to write software in the same way that knowing how to read and write doesn't just grant you the ability to join a legal team and start writing contracts.
>>doctors make mistakes that kill people all the time
Yes, but they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.
The standard is not perfection; the standard is as good as practical and better than if nothing were done. Medical licensing definitely meets both of those criteria. Unless you are arguing that anyone who takes a ten-week "Medical Bootcamp" is ready to be a surgeon you would trust to operate on you or your children?
Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
You have it exactly backwards — Credentialing RAISES the skill floor. It does not raise it to perfection, and "Certificates" in the computing industry are a joke, but real medical or engineering credentials certainly raise the floor higher than the software floor
> they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.
I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.
Milton Friedman wrote a PhD dissertation on the topic of medicine that I invite you to take a look at.
> than if nothing were done.
The alternative is not to invite people who have no experience to build bridges or perform surgeries.
There are no credentials to work at Google. But you’ll find very skilled and capable people running large projects.
Investors want capable people. Those people are vetted through their reputation in their professional circles.
> Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
No. But I would like to drive over bridges from people with 30 years of bridge building experience over a 4-7 year degree.
If you live in Europe you drive over bridges built without credentials all the time.
> Credentialing RAISES the skill floor.
Correct. That’s my mistake.
The point is if cut off the bottom 20th percentile the field doesn’t get much better. Those people aren’t trusted leaders anyway.
You do however lose a significant amount of upside. Including countless top performers from non traditional backgrounds, which is characteristic of computer hackers.
You can maybe argue that the general public, unlike a corporation is not capable of vetting their own doctor, so the government classified those options for them. And that’s reasonable. But that does not apply at all to software engineers who don’t solicit public work.
I have all the traditional credentials and this is not a projection of my own career.
> I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.
The medical boards are well aware of this, which is why the standards are far more than just about having more schooling.
I am familiar with Friendman's dissertation, and while the economic claims it makes are solid, it isn't a take down about the medical impact of the boards. It really doesn't say one thing or another about them. Let's put it this way: if you are going to inflate the cost of a service, it's hard if the quality of the service is terrible and easily replicated by someone else.
I appreciate your positivity. However it is difficult to reconcile your argument with the reality that executives at tech companies frequently behave in ways that satisfy the investors but clearly do not produce good results for the people using their technology. Indeed in numerous cases today the technology is openly hostile to its own users' interests. The regulations are there to protect the users (or customers or clients or patients). If anything they are there to prevent protecting the profit margins of the businesses - because hiring people to pump up the profits is often in conflict with the other objective.
What would credentialing software engineers do to curtail leadership incentive problems?
The same as in other regulated professions. It would give the people on the front line who can see the consequences of the corner cutting an effective right to say "No, we're not doing this user hostile thing". This would be a significant barrier because it wouldn't be legal to ship software without the required professional approval and the professionals would be heavily incentivised not to sign off any corner cutting because they would be personally and professionally responsible for any adverse consequences if they did.
That’s not how these systems work in reality. I’m actually an extreme pessimist.
What actually happens is that you as an engineer become paid to frame the desired leadership goals in compliant terms.
It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.
This skill among engineers is highly sought after in large companies with political organizations and greater encouraging it changes the composition of the workforce.
In the physical engineering teams I've worked with the culture you just described is not what happens at all. There are always some people who seemingly live to circumvent the intention of rules lurking around the edges of regulated industries. But my own experience has been that real engineers very much value real engineering - it's often why they got into the field in the first place - and will push back hard against and if necessary refuse to sign off anything they consider inappropriate for the job. They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.
Regulatory compliance is 90% social and 10% reality.
Again our experiences are on opposite ends of the spectrum. For safety issues in particular getting an engineer to sign off some plan when they will be accountable for that authority later is often easiest if you simply design the thing properly.
I have certainly seen compliance become a box-ticking exercise in other contexts but usually this seems to happen when the professionals involved were not personally responsible for their own decisions.
Imagine a new grad telling their boss “we aren’t going to build it like that because I learned X in school”. They have the same credentials!
We appear to live in different realities on this one too. In my reality new grads are not the people signing off major decisions in regulated industries and no-one would seriously suggest that a new grad's degree was an equivalent credential to the years of demonstrable professional experience and peer review that are typically required to reach a level of professional qualification where someone does have the authority to sign off those big decisions. Getting an undergraduate degree in a subject like engineering or medicine or law is just a foot in the door. The real work starts afterwards.
> For safety issues in particular getting an engineer to sign off some plan when they will be accountable for that authority later is often easiest if you simply design the thing properly.
That's exactly right. An engineer aims to build a safe and reliable product (not because the credentials tell him to)! The regulatory myth is that all products are death machines until being redeemed.
That's why I say it's 90% social. The engineer builds a reasonable product. With regulation they do the same, but now they need to do work to frame that same work in regulatory terms.
Real fixes are made. The value isn't 0, but it comes at that cost.
> no-one would seriously suggest that a new grad's degree was an equivalent credential to the years of demonstrable professional experience
That's exactly what I'm saying! Professional experience and reputation within the field is what:
1. gives someone influence and credibility.
2. results in safe and reliable engineering projects.
And note that those are actually informal defined qualifications. It's NOT the credential!
So trying to add credentials to software is an attempt to bump the quality of new grads and has little to no impact on the quality of engineering leadership. As you said, the recent undergrads already lack power and influence, and the credential is simply the bare minimum to participate.
> They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.
It really depends on the status of the profession in society and the company. I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.
I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.
No doubt. Imposing this kind of professional standards to regulate an industry as rich as tech would never work unless the penalties for cutting corners involved making the offending organisations significantly less rich very quickly. They would need to be taught a very clear lesson that hiring people pleasers had become an expensive mistake.
As I commented elsewhere - the problem then becomes who gets to define what the proper path is. For example destroying companies because they chose not to follow the latest sage advice from anyone who once signed the Agile Manifesto does not seem like a good way to promote better quality software to me. And yet it seems highly likely that those are the kinds of people who would initially be engaged as "experts" by those seeking to establish the regulatory environment.
I don't want people like them. I want the quiet, unassuming developer you've never heard of because they're the principal engineer of a team you've also never heard of that has been developing life saving medical equipment without a single significant failure in a live environment for the 15 years since their first device went into use at a local hospital. Get me those people to write the rules - starting with what is acceptable practice when developing software that really needs to work and letting the people who know how to achieve the most challenging results figure out how to tone everything down for applications where imperfections might be more acceptable - and then we can talk about whether regulating software development effectively is now a viable proposition.
> As I commented elsewhere - the problem then becomes who gets to define what the proper path is. For example destroying companies because they chose not to follow the latest sage advice from anyone who once signed the Agile Manifesto does not seem like a good way to promote better quality software to me. And yet it seems highly likely that those are the kinds of people who would initially be engaged as "experts" by those seeking to establish the regulatory environment.
This is why any such regulation is likely to end up in a much better state if it's driven by actual practitioners. However, given how many software people are wildly against this, it seems unlikely to happen and so we'll end up in the less good state you note above.
It looks like we agree here. I too think any useful regulation should be specified primarily by experienced practitioners who have been achieving demonstrably good outcomes. And I too think that in reality it would mostly likely be a very different type of person who got to write the rules - which is why I don't think our industry is ready for that kind of regulation and I believe introducing it now would be counterproductive.
> It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.
This is true, and basically what tends to happen is that if the Head of some compliance function (e.g. internal audit) is causing problems for the business, then they are replaced with someone who won't cause such problems.
It's still better than nothing. Like, software basically runs our society now, so either software professionals get together on this, or regulations will be imposed on us, and they will be much worse than what we'd get in the first option.
Once again the alternative is not nothing. The most important factor is that they are stakeholders in a project with influence. That is the reality right now, even without credentials.
Yes the framing above is “business people don’t listen to engineers but if they had a credential they would legally be forced to”.
And I think both are false.
The top engineers on a project are collaborators with leaders in other areas like marketing, sales, IT, legal, etc. And all those have influence on a project. A business person who says “fuck what my engineer says” is not a good leader and won’t have that group’s trust or support. They all want to work together.
So by that process engineering has a seat of influence.
That exists without credentials, and credentials are not what gets you in that seat. Reputation and experience are.
Business leaders don’t do everything engineering says. They also don’t do everything the lawyers say! And having an additional legal backing would change some of these engineering conversation, but not fundamentally.
More credentialing and requirements would do plenty to curtail leadership incentive problems. First, as the sibling points out, it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order — "I'm not going to lose my license for that stupid idea", and a serious incentive to do so, as well as solid job prospects if he does get canned for it (because there's a limited pool of credentialed engineers).
You glibly say "More schooling does not mean more trustworthy or careful doctors.". Yet the schooling and credentialing clearly cuts off huge numbers of would-be doctors who never pass the exams, never graduate med school, or never even get into med school, or decide it is too difficult in the first place. In the software realm, those people just go to some boot camp and they're off to the races...
Another huge aspect of credentialing is required ongoing education, which REQUIRES physicians and engineers to take updated continuing education just to maintain their license. This again continuously improves the talent pool.
And, if your main concern is that they be "more trustworthy or careful", credentialing also helps that by finding the worst, least trustworthy and careful and cancelling their license, so they are NOT doctors anymore. The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere, probably taking one from the actual good engineer because their talent is not engineering, but bullshitting.
> it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order
I disagree to the extent to which this is real leverage. It changes the language and approach, but not the outcome, Ask a civil engineer the degree to which they can fight their leadership on these grounds.
> clearly cuts off huge numbers of would-be doctors who never pass the exams
Yes the fallacy is that more exclusive is better. You don’t understand the traits you select for.
> those people just go to some boot camp and they're off to the races
I don’t see any kids who just got off a boot camp running large software projects. Does this happen at your workplace? Why not?
> This again continuously improves the talent pool.
I just disagree to the extent to which the talent actually increases.
The people who excel already learn and study all time.
This slightly raises the floor by forcing the least curious person to be exposed to some PowerPoints and videos.
> The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere
They can only ruin the extent of responsibility and scope given to a new hire with no reputation.
> least trustworthy and careful and cancelling their license
Once again you assume the system works as stated. I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
The image that comes to mind is someone who made a mistake, cares a ton about medicine, and hates the organizational administration.
Wow you have a relentlessly unrealistic view of things.
>>Ask a civil engineer the degree to which they can fight their leadership on these grounds.
Both civil engineers and doctors both can and absolutely do refuse to sign off on unsafe situations.
That does not mean they detect them 100% of the time, or never cave to pressure, but they absolutely do. We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action — precisely because nothing newsworthy happened. We DO hear about the ones that did happen, Therac-25, Mars Climate Orbiter loss, Cloudflare outage, it is endless
>>I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
You might think that, but clearly you have never read even the summaries of cases where doctors lost their licenses. Hint: it was not some mistake that could have been covered up by better schmoozing. If anything, the system is too lenient.
The rest isn't even worth the bytes to respond; just handwaving an attitude. There are very good arguments to not have licensing on software engineering but you are not making them
> Wow you have a relentlessly unrealistic view of things.
I noticed from your response that you didn’t really refute the claims, but that suggesting that systems don’t achieve their stated goal gives you a distasteful feeling.
> We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action
And the same is true of software. I and my peers tell my bosses ideas are bad all the time. We don’t need a credential to do that. And the credential is not what gave us trust with that decision maker.
> If anything, the system is too lenient.
Correct. Bad doctors continue to keep their jobs all their time.
So that’s my point. What is the criteria that distinguishes those cases? Both doctors made a medical error. Which one gets off and which one gets fired? The doctor who is more focused on medicine is likely the one less skilled at navigating the legal problem.
The doctors making mistakes and keeping their jobs are a pathological minority that is reinforced by their credential giving them authority to operate.
Cold call job interviews are primarily for people early in their career to get established in the field. You don’t hire someone that way to lead the Golden Gate Bridge.
How do you think companies hire for key roles like CEOs?
> software engineering aught to be a licensed profession
Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.
It's not licensed per se, but in certain areas of the defense industry, one is restricted to using the 'DOD approved' subset of C++. Coders that know how to be productive within those constraints (and can pass clearance) are much more rare than your average code monkey
I think a more effective way of enforcing the licensing would be adding a cyber insurance requirement to sell software or internet services commercially to some threshold of users. Insurers could give a prime rate to licensed developers and offer a service to have their own engineers certify software from firms without credentials for a higher rate.
Direct licensing requirements from the state are prone to abuse via regulatory capture. Big or entrenched players can give to politicians who’ll change the rules in their favor, setting who needs a license and who can get one.
The profit maximizing incentive for insurance is a double edged sword, but if there’s a government backed insurer that just does the prime rate for licensed developers, the commercial market can build off that and fill in the gaps.
If you need a special license and insurance to drive a commercial truck on public roadways, why not the same for commercial traffic on the public internet? A good way to drive adoption from nontechnical folks could be something like the lock icon in the browser for TLS. Issue a domain cert for certified software, you can go to their website and confirm they are compliant right away. People are free to publish and use non-certified apps, they just won’t unless they have a reason to trust them.
Licensing is not a substitute for hiring competent people that actually care about the quality of their work, and then giving them the time, resources, and support they actually need to do it.
Government involvement almost always just makes the problem worse, not better. There is a place for control in some areas (medical, military applications, etc), but I think broad-sweeping regulation would do far more damage than good.
Eh, I've never been a fan of licensing simply because software engineering is a vast field with huge differences in the impact your work might have.
Like sure, if you're writing software for medical professionals, or lawyers, or aviation companies then I can see that being something you'd want people licensed for. A major bug in a pacemaker or plane's autopilot system is a huge deal that could injure or kill a lot of people.
At the same time though, a lot of software engineering/programming work is extremely low stakes, and I think expecting that to be licensed would be kinda ridiculous. Having someone need to be licensed to create a small business WordPress site, or local desktop software to solve a personal need, or most video games in general feels kind of absurd. Do people need to be licensed to make say, Minecraft mods or hack a game from the 80s?
The difference with the legal and medical industry is that if someone is incompetent or screws up in those fields, there are almost certainly going to be negative, if not dire consequences for those involved. If someone screws up in tech, then there may be dire consequences in some industries/sub-fields, or no/positive consequences in others.
People doing "mechanical engineering" in their garage don't need licenses either. I don't love the licensing idea either, but that's not a good argument.
>Why would we restrict other creative work in this way?
Because it isn't creative work. Software underpins payment processors, medical services, emergency alerts, infrastructure. In the UK not long ago a ransomware attack took the healthcare system offline and surgeries had to be postponed. in 2021 the Colonial Pipeline attack took 50% of the US East Coast's oil supply offline. The entire German train system died a few weeks ago for half a day because of a software bug.
People's entire communication is in digital services, all of their private data, the economy grinds to a halt or national security is impacted monthly now by either deliberate attacks or just bugs.
you license both. When you go in for surgery your hospital is accredited and the surgeon who operates on you is licensed. I don't even understand what you're trying to argue, you're okay with being operated on by a guy they found on craigslist as long as the hospital has a license? We should bridges let bridges be built by engineers who took a few courses on Khan Academy?
Of course professionals themselves need to be licensed, how else is any company supposed to have any confidence in who they employ or any legal security?
Mostly rendering. A bunch of images, text, UI elements. On a modern high resolution display it adds up quite quickly. You can surely cut it down a bit, but 100MB isn't absurd.
A weather widget using 8 bit color plus alpha on a 4k display show three full size images in 100mb. But I suspect that's not the ux we're talking about here, and a widget style system has no excuse.
Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.
The display on that page is literally broken for me, the boxes are all misaligned. It seems like it can't handle Japanese text correctly. Properly working localization in dozens of languages is one of those things that adds "bloat" to modern software that was missing in the bad old days.
If I full-screen it in high enough resolution it can be excused for using 100MB temporarily.
The window in the article wasn't very big. At most it would have about 10MB of framebuffer, and the images on display would fit into 1MB uncompressed.
We can't excuse typical program waste with screen sizes. Especially when you can switch to 1080p or 720p and watch them still use massive amounts of memory.
I think this depends on your location, because in some places you really want to view a radar map. "Rain in $CITY" is practically useless for me. Still, the (static?) map in the depicted app shouldn't take 1GB.
> easier than ever to just maintain and keep your fork of software with the changes you want or need
I don't imagine this is practical or desirable for all situations. Good software is built from being battle tested by many users in many environments. Even with the advancements in AI tools, I don't imagine they'll become omnipotent anytime soon.
> No more approval, bureaucracy, or arguing
For software that can kill people or substantively affect someone’s life in a negative way, the bureaucracy is there for good reason. I don't think anyone should want someone at Phillips to vibe code the control software for an X-Ray machine or an employee at CrowdStrike vibe coding the next update before pushing it out to millions of machines.
We are forced to endure low-quality software because there is little or no accountability. I can only imagine what you propose would make an already poor situation worse.
Unfortunately Americans remain too comfortable to bother with any serious push back. The destruction of democratic traditions in America will continue and the president will keep using the office to legitimise his scams.
Or at least, the tech-bro subset of the general population. It's possible that they're disproportionately vocal on HN, but I think overall it's a reasonably accurate presentation of that (narrow but powerful) demographic.
I dont support Trump, but the conscious part is closer to me.
Why would you think LLMs are not conscious? Maybe a link to an article that is aligned with your views? That would help me understand your viewpoint.
Are dogs conscious? Maybe not, or a bit so. LLMs are more conscious than dogs.
LLM are deficient in certain memory aspect - particularly a gap between the generation cycle and the context window. So they seem forgetful. But people with memory loss or damaged hypocampus are still conscious. LLMs are dumb in certain aspects, do weird errors, but we still agree that dumb people with weird errors are conscious.
Theory wise thinking is likely substrate independent. Unless you think that biological tissue holds some life force that allows to transend comoutation limitations somehow.
Thats probably not what you wanted to read, Im aorry. Just really curious in how do you reconcile all of this.
Do you think diffusion models or models that generate video and image are conscious? I'd say most people who think LLMs are conscious don't think the same way about non-chattng models ( unless you ask them then they might say "sure" in an attempt to remain consistent).
My point is it's the interaction medium that's causing the confusion and causinf this psychosis that's tricking people into feeling like they're talking to someone.
LLMs are not conscious, sams as google chrome, same as GTA 5, same as your latest python script.
I'm not sure that's a bad thing. I suspect with increased friction, users are more likely to scrutinise dependencies before importing them.