* Posts by odyssey

10 publicly visible posts • joined 4 Mar 2020

Tiny Linux kernel tweak could cut datacenter power use by 30%, boffins say

odyssey

Garbage Collection should be the next to go. Developers have got lazy and dumb relying on someone else to manage their memory. So much efficiency could be gained looking at more efficient memory management. Rust, Zig, C, or something else - Deepseek and now this has shown that there are real software efficiency improvements to be made but only perhaps 10% of developers understand things well enough to make them.

Decade-old bug in Linux world's sudo can be abused by any logged-in user to gain root privileges

odyssey

But it seems to keep happening. It happens dozens of times a year including in code maintained by very experienced developers. The sudo maintainers are not n00bs. At some point we need to acknowledge that the C language makes this kind of error too easy to make, and that for all userspace programs some safer alternative is a priority.

odyssey

Bounds checking is necessary but has a performance hit

Some commenters think automatic bounds checking solves the problem fully. It doesn't. If you get length calculations wrong in Java, you get a StringIndexOutOfBoundsException, an ArrayIndexOutOfBoundsException, etc. Same for other managed languages.

It doesn't solve the underlying problem, just mitigates it to a handled crash rather than a vulnerability. That's a lot better though, and most userspace programs should move off C for higher level languages with better string handling. But if you get the code wrong, you always get an issue - it's just that in a safe language it's an exception that's not exploitable.

After ten years, the Google vs Oracle API copyright mega-battle finally hit the Supreme Court – and we listened in

odyssey

Programming is partly logic, partly art

The difficulty for the justices who I assume are not programmers is that programming is partly logic, partly art. Copyright is simple when it comes to art - Harry Potter is a creative work, if I wrote a book and had a school called Hogwarts I would be obviously copying it as I could have called the school anything else.

But when it comes to programming, there are many ways to express something (which is why programmers argue endlessly over languages and styles) but only so many ways to implement something. So if someone has a function called rangeCheck I could call my function examineTheRange just to be different, but I'm doing the same thing. I need to check if one number is greater than another, etc. I can call my variables what I like but I can't change what the function does. Logic means you can't make up what you like, art means you can - and software is a bit of both. This is going to be hard to understand for the justices because Oracle are going to use analogies with literature. But literature isn't a good analogy because you can always do whatever you like in your own novel. In programming you can't. And classes of functions are going to be limited - a File API would have open, close, read, write, etc - even if called something else to get around a copyright troll.

What's needed is an update of international copyright agreements, a Berne Convention 2, that fully recognizes that software is different from literature. And protects APIs from being copyrighted by recognizing them as logical expressions rather than creative works.

Excel Hell: It's not just blame for pandemic pandemonium being spread between the sheets

odyssey

Blame the user not the tool

This reminds me of Bjarne Stroustrup's observation that there are two kinds of programming languages - the ones people complain about and the ones nobody uses. Excel is a good general-purpose tool for what it's meant for. There are lots of horror stories because it's so widely used. Any other tool that was as popular would have people misusing it. Most of the horror stories listed are human error.

Having said that, Excel is not meant to be used as a database (why MS makes Access and SQL Server). It's not MS or Excel's fault this happened, it's people stupidly importing csv files into a spreadsheet program when databases are the right tool for the job and freely available.

Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes

odyssey

Re: What's this, a bug caused by a language quirk?

No I don't deny that. Higher-level languages make exploitable buffer overflows impossible, for example. They should be used for front-facing systems where possible, and usually are. This bug however isn't due to low-level C memory handling, neither are many other bugs. Therefore it's more rigorous testing that's needed.

odyssey

Re: What's this, a bug caused by a language quirk?

"goto fail" specifically couldn't have happened in languages where "goto" isn't a thing. But you can create logic errors in every language. As we've seen with this Let's Encrypt bug, you can construct logically wrong code. You could write the equivalent of "goto fail" in a "goto-less" language, by getting a break or termination condition wrong.

For example the Zune player bug where a missing break clause in date calculation code caused an infinite loop. All languages could have such a bug, the language itself can never prevent it. That's why we need careful, rigorous testing. These bugs should really be seen as testing failures. A failure to verify that the code is correct in every possible condition.

odyssey

Re: What's this, a bug caused by a language quirk?

I wouldn't say deserialization is a language quirk or gotcha. It can be used unsafely, but so can anything that lets untrusted users do things. Go's use of loop variables, the difference between = and ==, etc are gotchas because they look like they should do something different to what they actually do.

odyssey

Same, I have thought that Go looked interesting as a language. But if it behaves in counter-intuitive ways, it clearly hasn't been thought through that well.

odyssey

Re: What's this, a bug caused by a language quirk?

I'd say Java has very few gotchas. Other than equals() vs == it's hard to make silly mistakes.