Live data from Hacker News

Obvious and possible software innovations

scottlocklin.wordpress.com

141–150 of 157 posts

Re: Obvious and possible software innovations

#141
post #138

Earlier quoted context omitted.

I took his point in general to be a rant about the unwillingness to give priority and effort to things that are schleppy, but doable. An unwillingness to address the devil in the details. The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly. I would take the detail he gives for the specific cases as incomplete…

I respect you for generously steelmanning the OP's argument here but it is very clear the OP's intent is "just parse C header files and do it all automatically": > not only could you technically parse .h files and turn them into JNI Well, no, technically you can't do that at all.

OK. Fair interpretation.

The OP didn't have much leg to really stand on for this point and glosses over any of the actual difficult work that would need to be done to make this utopia from the 70/80/90s materialize.

It's not a great post, and its ideas are not that clearly worked out. He could seriously work on his tone.

It could be parsed minimally as a just a grumpy rant with a bit of "get off the lawn" and a few wrong ideas.

Mostly a waste of time.

I'm steelmanning it because personally I'd prefer to get as much as possible from what I've read. Even if it wasn't necessarily put it in the first place (maximizing my utility from it, for my purposes). I'm not debating the OP.

If you're acting from a position of keeping him honest. Kudos.

So I don't really need to engage you on the point then.

I'm agreeing that you'd probably be able to take down the OP in an argument. Or at least would force him to up his game considerable to be able to actually make his points clearly.

BTW, I really like your use of "steelmanning" here.

Actually looking at his other points after this exchange:

(2) I think modern VMs have amazing engineering - is he asking for hacks? Or what?

(3) Cloud offerings could be more coherent. But there are real market and organisational constraints.

(4) Drag and drop UI designers would be nice, and I miss them, but even the good ones used to produce terrible code when used innocently.

(5) I think modern compilers are pretty awesome. Not sure what he wants done.

(6) Yeah. We could build better more compact systems.

His unhappiness at the state of the world.

Hmm. Moaning about it like that doesn't really do much to solve it...

Re: Obvious and possible software innovations

#143

Earlier quoted context omitted.

> The size of the final package is not very important You can only install so many packages with this philosophy before size starts to be important after. More to the point, you can only run a few of them at a time, on machines with gigabytes of RAM. This is a profound embarrassment to our industry. If by "responsive" you're referring to input latency, Electron apps are at best on par with native, usually worse IME.…

I understand the performance criticism. But people don't have that many apps, storage is cheap and we have plenty of ram. Today a high end smartphone has 128gb of storage and 8gb of ram. Some have 512gb of storage and 12gb of ram. An actual high end desktop computer has at least 64gb of ram and enough storage to have quite a lot of Electron runtimes installed side by side. My M1 MacBook pro with only 8gb of ram, I as…

> "But people don't have that many apps, storage is cheap and we have plenty of ram."

Appliance maker: "Electricity is cheap and there's plenty of it, who cares if all the devices we sell costs the consumer on their electricity bill and causes power plants to pollute the atmosphere more."

Car manufacturer: "Fossil fuel is cheap and there's plenty of it, who cares if all the cars we sell cost the customer extra at the pump and adds to air pollution."

There was a reckoning for both of those fields and there will eventually be a reckoning for software development as well.

Re: Obvious and possible software innovations

#144

Earlier quoted context omitted.

What value is an opinion if you can't back it up?

David Hilbert published a list of 23 open problems in mathematics near the turn of the 20th century, and they served to goad the mathematics community into action for the next 75 years at least (some are still unsolved, but most were solved). Saying "this is a problem that should be solved" might betray a lack of knowledge of an existing solution, but hand-waving such an assertion away and saying "he can't back up hi…

That person is no David Hilbert.

As multiple comments says, many of the problems he talks about are already solved. And some of them were solved in the past and solutions abandoned.

If you want to learn something, you will be much better off starting from a post which does not ignore existing state of the field.

Re: Obvious and possible software innovations

#145
post #144

Earlier quoted context omitted.

David Hilbert published a list of 23 open problems in mathematics near the turn of the 20th century, and they served to goad the mathematics community into action for the next 75 years at least (some are still unsolved, but most were solved). Saying "this is a problem that should be solved" might betray a lack of knowledge of an existing solution, but hand-waving such an assertion away and saying "he can't back up hi…

That person is no David Hilbert. As multiple comments says, many of the problems he talks about are already solved. And some of them were solved in the past and solutions abandoned. If you want to learn something, you will be much better off starting from a post which does not ignore existing state of the field.

I'm mostly interested in this post because the contrast he draws between AWS and z/OS deeply resonates with me.

What if someone built an OS to deal with cloud-scale problems at the ground level - in the kernel? This isn't to say the likes of S3 or DynamoDB should be implemented in kernel space (far from it). But the mishmash of services AWS does offer seems to be more about solving cloud-scale problems without implementing an OS, while creating a lot of DevOps jobs and a ton of vendor lock-in.

At this point, AWS reminds me a lot of Windows Server: lots of UI, object-heavy scripting, a huge suite of expensive vendor-specific products, and a sheer inelegance about how the whole thing is built.

I also see a lot of personality similarities between Windows admins in corporate IT of the 2000s and today's AWS DevOps professionals.

Linux finally took down Windows Server because it had superior qualities as a development OS and was cheaper to run on server hardware. It also had a long history of people just building cool stuff on it...

I have no idea what innovation will finally take down AWS, but perhaps mainframe OS's are a promising trail to go down (if infrastructure-as-code could be applied).

Re: Obvious and possible software innovations

#146

Earlier quoted context omitted.

I understand the performance criticism. But people don't have that many apps, storage is cheap and we have plenty of ram. Today a high end smartphone has 128gb of storage and 8gb of ram. Some have 512gb of storage and 12gb of ram. An actual high end desktop computer has at least 64gb of ram and enough storage to have quite a lot of Electron runtimes installed side by side. My M1 MacBook pro with only 8gb of ram, I as…

> " But people don't have that many apps, storage is cheap and we have plenty of ram. " Appliance maker: " Electricity is cheap and there's plenty of it, who cares if all the devices we sell costs the consumer on their electricity bill and causes power plants to pollute the atmosphere more. " Car manufacturer: " Fossil fuel is cheap and there's plenty of it, who cares if all the cars we sell cost the customer extra a…

I am a bit too lazy to do the maths, but I would guess that a single Electron development team consumes a lot less energy than many native development teams.

Re: Obvious and possible software innovations

#147
post #63

I really dislike the article, here are some reasons (referencing the numbered arguments in the article). 1. There are many such parsers. Rusts bindgen [1] is one of them, I have written a proprietary one last year. This is pretty common to do for narrow use cases, there just isn't one for "Convert a C API to Ruby".. 2. "Most VM designs I’ve seen are basically just student exercises". Seriously? Create a better on and…

Look, I agree that the article could've used a more productive tone but saying "just don't use Electron apps" is misguided.

We don't have a choice. IMO it's perfectly fine to be consistently unhappy on that point and to rant about it.

Re: Obvious and possible software innovations

#148
post #83

Earlier quoted context omitted.

fuchsia seems like a solid attempt by goog to write a ground up os

What are the advantages/disadvantages of Zircon over seL4? I've read up a bit on seL4, but can't seem to find the rationale or design decisions behind Zircon. Not sure why Google needs to roll their own microkernel when there is a fast, secure, formally verified one they could use.

A web search shows some speculation suggesting it could be Zircon's larger feature set and a desire for an in-house ground up solution.

Fuchsia leads are on twitter; they seem very nice and some have open DM's. They'd probably be happy to answer

Re: Obvious and possible software innovations

#149
post #144

Earlier quoted context omitted.

That person is no David Hilbert. As multiple comments says, many of the problems he talks about are already solved. And some of them were solved in the past and solutions abandoned. If you want to learn something, you will be much better off starting from a post which does not ignore existing state of the field.

I'm mostly interested in this post because the contrast he draws between AWS and z/OS deeply resonates with me. What if someone built an OS to deal with cloud-scale problems at the ground level - in the kernel? This isn't to say the likes of S3 or DynamoDB should be implemented in kernel space ( far from it). But the mishmash of services AWS does offer seems to be more about solving cloud-scale problems without imple…

AWS does not have to be "lots of UI" and "Windows admins" -- Terraform, CloudFormation, and other infra-as-code solution are totally a thing, and bring modern, UI-less practices to to infrastructure services. If you are in the company which has corporate culture of "let's use AWS todaly like we used Windows 20 years ago" it may seem that the whole world is like that.. but it is not, there are plenty of other companies with different cultures!

Re "OS to deal with cloud-scale problems at the ground level - in the kernel" -- I cannot make sense of that. Why on earth would it matter which OS do services use? For all that I care, Amazon could rewrite DynamoDB using AmigaOS and I would not even notice. It is all the same HTTP calls -- and this is one of the good things about the system. People can use AWS services from windows, linux, mac, mobile, even things like FreeRTOS, using any programming language they like. I guess you can create one more OS which is designed with AWS use in mind, but I doubt it will be a big game changer.

Re: Obvious and possible software innovations

#150
post #128
post #87

Earlier quoted context omitted.

> I just love the idea of one big central computer doing all the processing. And yet at the same time, having a super computer in my pocket is spectacularly cool!

Which can only siphon your data and play games.

You can run your own code on your phone. Even iOS lets you do that (I don’t even think you need to lay the apple developer fees to do that?) You just can’t widely distributed it in easy for other people to run form. You _can_ give your friends .apk files. You _can_ write iOS apps that violate App Store rules. It’s the “publishing” bit that is locked down.
Post reply on HN