I agree with every word about the BYD, in fact I just recently helped a family member buy one. But how would you pick the Austin 7 over the Model T as your example revolutionary car? Serious question, you're obviously knowledgeable if you mentioned that vehicle.
You can check the video on the early generation cars reviewed by the famous Top Gear team members [1].
Austin 7 and its derivatives (notably Dixi that kickstarted the highly successful BMW car business), dictated and popularized the modern car architecture, interfaces and controls stereotype as we know today. In order to drive old cars prior to Austin 7, we probably need a manual before we can drive them except the Cadillac Type 53 car, the original car that heavily inspired the Austin 7.
Austin 7 is the lightest car and cheapest proper car of its generation, and even by today's standard and inflation. As crazy as it sounds you can even drive it now in the UK road without any modification [2].
It become the template of modern cars, made popular in the UK, Germany and Japan, and then the rest of the world since these three countries are major manufacturers of modern cars.
The lighweight and low cost price of the baby Seagull (smallest BYD), is very similar to Baby Austin (popular name for Austin 7 in the UK) innovation criteria.
[1] Jeremy Clarkson and James May Find the First Car [video]:
Jaguar only started using a synchromesh gearbox in the E-Type in '65 or '66 (Series II) - that's forty years after the Austin. I have no idea why the British love to abuse themselves.
Last week I saw some old Rolls Royce that I absolutely could not guess even the decade of. The carriage looked 1930s but the interior looked 1950s - until I noticed what might have been spark advance levers on the steering wheel. It's a super luxury vehicle with super conservative styling, so I really don't know if it had a luxury interior for it's time or a classic exterior for it's time.
> How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?
First 80% of a job typically takes 80% of the allocated time. The last 20% of a job typically takes another 80% of the allocated time.
They readme suggests that it supports PHP back to 5.3. PHP 7.2 and 8.0 were huge compatibility leaps for the language. None of my 5.3 codebases would run on 8.1, which the readme also suggests, and none of my PHP 8 codebases would run on 5.3. This must be using such a small subset of the language that it would be difficult for a human to maintain it. Especially considering that no third party library would ever be able to run on those two versions.
For PHP 8.5 code to work with PHP 5.3 you'd have to forego short array syntax, finally blocks, scalar type hints and nullable types (OK, you mention this), the ?? operator, the ?-> operator, traits, and probably a million other things that we use every day.
For PHP 5.3 code to work on PHP 8+ you'd have had to completely forego error catching because that was completely upended in 7.0 or 7.2 (I forget which), not used short open tags, never used the class name as a constructor (that happened a lot in PHP 5), have no mcrypt functions, not used __autoload(), have had the foresight to use PDO instead of mysql_ (was PDO available in 5.3? I'd never seen it that early I think), you'd have had to be fortunate enough to not used ereg_, I think that older versions used # in ini file comments (I remember that breaking at some point, don't remember when), never used each(), not used safe_mode for mysql (strange because that was the default I think), and probably a million other issues that I hadn't encountered. If you have codebase written for PHP 5.3 that still works on modern PHP, I'd love to see it. I honestly don't believe such a codebase exists beyond the most trivial.
Most of the apps where developed for php 5.2-5.3 , as many things that you wrote where already bad code in this time.
Spl autoloader, MySQLi, __construct was already available.
The apps are internal legacy apps so I can't share the codebase.
Because of this there was no big rewrite like types etc.
This looks absolutely terrific if it is performative. How long does this library take to generate the thumbnails and the seek bar for e.g. a 60 minute video, on 8-year-old desktop hardware? Or on older mobile devices? For reference, my current desktop is from 2012.
To answer your question: VAM-Seek doesn't pre-render the entire 60 minutes. It only extracts frames for the visible grid (e.g., 24-48 thumbnails) using the browser's hardware acceleration via Canvas.
On older hardware, the bottleneck is usually the browser's video seeking speed, not the generation itself. Even on a 2012 desktop, it should populate the grid in a few seconds. If it takes longer... well, that might be your PC's way of asking for a retirement plan! ;)
I had Claude run rm once, and when I asked it when did I permiss that operation it told me oops. I actually have the transcript if anybody wants to see it.
I'm using an LLM to write the code for my current project, but I iterate improvements in the code until it looks like code I wrote myself. I sign off on each git commit. I need to maintain and extend this code, it is to scratch my own itch.
LLMs are capable of producing junk, and they are capable of writing decent code. It is up to the operator to use them properly.
“Take this CSV of survey data and create a web visualization and create a chloropleth map with panning, zooming, and tooltips” I bypass permissions and it’s done in 10 minutes while I go do some laundry. If I did it myself I would not even be done researching a usable library and I would have zero lines of code. Those studies are total nonsense.
LLMs excel at tasks that are fresh. LLMs are wonderful at getting the first 80% of the way there. -- LLMs are phenomenally good for a first draft or so.
I've had worse experiences for getting LLMs / agents to refactor code. I would believe in many cases it could be quicker to just manually go through and make refinements compared to merely getting the LLM to keep trying.
That seems very intuitive to me. If you want extremely specific changes made at extremely specific locations in an extremely specific way then you probably need to do that yourself because a language model can’t read your mind. I think there are very large set of problems where implementation details do not actually matter and cheap, disposable code is not a problem. I don’t think vibecoding is a good idea for missile guidance. Probably OK for a dashboard a manager isn’t really going to use anyway.
Right? The general case just doesn't make sense to me when people do that, where "that" is "I have a problem with person/organization, but rather than talk to person/organization about thing, I'm going to complain about it to everyone except person/organization and somehow be surprised that problem never gets fixed"! Like, how do you want things to get better?
These are "AI"-addicted developers that you're talking to.
They have been tricked into a world-view which validates their continual, lazy use of high-tech auto-generators.
They have been tricked into gleefully opting in to their own deskilling.
Expecting an "AI"-addicted developer to file a bug is like expecting an MSNBC or Fox News viewer to attend a town meeting.
The goal of "AI" products is to foster laziness, dependency, and isolation in their users.
Expecting these users to take any sort of action outside of further communication with their LLM chatbots does not square with the social function of these products.
Edit (response to the guy/LLM below me):
Hackernews comments written by fearmongering LLM idiots will tell me to "keep an open mind" about dogshit LLM chatbots until the day I die.
LLM technology is garbage.
If these tools are changing the world, they're only doing so by:
1. Dramatically facilitating the promulgation of idiotic delusions
2. Making enterprise software far, far more vulnerable than it was even in the recent past
this is a lazy take. all software has bugs and defects.
part of what we do, as developers is to learn. to have an open mind to new tools and technologies.
these tools are… different, they’re changing the world (fast), and worth trying to understand. your mental rigidity to doing things “the right way” will hold you back and limit your growth. the world is changing. are you?
Those tools are massively overhyped and hemorrhaging money by the second. Such a shame so many people are so blind as to not be able to take things with some realism and a non biased POV. They're great, yeah, they help for a lot of things, some people really "vibe" with that kind of workflow, good for them.
Everytime you "prompt" and you "vibe" you're not "changing with the world", you're using copious amounts of energy on very expensive hardware that you would never, in your lifetime, would be able to use if it wasn't backed by trillions in VC funding. Don't believe me? Try to match the performance of a current model with local hardware, report back with how much that costs in hardware and energy.
They're all in the stage A of enshittification, the bait phase. You're willingly making yourself reliant on a tool that eventually will be uncostable for any individual, and only affordable for big orgs.
If the job of a developer is to "learn, and have an open mind to new tools and technologies", and "my mental rigidity to doing things "the right way" will hold me back and limit my growth", then I don't want to be an engineer. Because one thing is to experiment, and another one is to, pardon the expression, suck off any new technology as the new epitome of anything. I don't want to be a "developer" with no criteria. Call me an engineer instead, I do things "the right way", and I don't fall prey to fashion under the guise of "growth".
Attending council meetings as a citizen observer is a huge waste of your time. The council already knows how it’s going to vote. The whole public-facing legislative process is community theater.
If you are already mentioning rocket propulsion, then you should know that Gwen Shotwell foresees Starship flying E2E (point to point on Earth) flights with paying passengers, competing with airlines. One hour to anywhere on the planet.
Hopefully we discover some sort of gravity physics/tech that makes chemical rockets obsolete!
I don't see Starship being useful for civilian transport use cases, but for military operations sure! But there's not much to distinguish a starship from a nuke launch during a war, so it remains to be seen whether that risk is worth it.
I can imagine Starship landing on a sea launchpad (in coastal cities), and the last 30 miles can be taken by a speedboat in half an hour. The sea usually isn't as traffic-jammed as land communications, and boats, unlike high-speed trains, don't require that much infrastructure.
Which is nonsense. Not only will rockets never have airplane reliability and safety for basic physics reasons, but that rocket profile looks exactly like an ICBM and nobody wants to let that confusion happen.
Airplane flight trajectories look exactly like a V1 missile, and even modern tomahawks could be made to fly such a profile. Or it could be a subsonic B-1B instead of a Boeing 747. Solutions to IFF have decades of development.
reply