Posts by teknopaul 1484 publicly visible posts • joined 11 Mar 2011
I worked in a bank that screwed-up approx 20% of transactions.
Wide boys on phones on the shop floor would be doing crazy trades all day, some of them with terms agreed on the phone, without known risk and these were written down on bits of paper and entered into a system that had a target of handling 80% automatically the rest were signed by hand or cancelled.
Banks _regularly_ screw up transactions and _usually_ fix them up.
Systems like visa are more reliable.
Of course, Bitcoin and AltCoins are sometimes unable to achieve the hash rate to complete any tx.
Maybe they are looking at the success of other open source projects and thinking this could apply to hardware too?
It may not make sense to screw the platform you are heavily invested in?
Perhaps Arm will die and RiscV will grow for exactly this reason, and the early adopters will benefit the most?
Just a thought, but that is what most people are explicitly saying, and at first glance it seems to be working rather well.
It will be interesting to see in the coming months how many game developers change their tactics.
I suspect close to zero. Perhaps minus zero as apps move to app stores to swallow the blame.
And any minor change in app store policy makes waves in industry.
A lesson indeed.
It's a mistake to think that sha256 "can't happen" or "nobody can make a collision".
Assume it can and make sure nothing too bad happens.
Assume it will and that nothing too bad happens on that day and you can rapidly change.
Relying on any one layer of security is a problem, having one "broken" but quite fast and easy layer in the stack it not a problem.
You can totally "rely on sha1 for security" as long as you don't rely on it to provide collision resistance when inputs can be manipulated. And are not interested in dictionary attacks (if you are concerned about dictionary attacks none of the other sha hashes are recommended)
Still plenty of good use cases: many in security.
Sha1 fine for a checksum shorter that 256 bits.
Signing a cert is not one of them (can't control inputs) but there are plenty of signing uses cases that would be valid except for the fact that security bods will probably fail your audit. In which case you can do a sha256 hash and crop it to sha1 length.
Derefing null is a problem but one Java doesn't face. They have null and throw NPE if you try to dereference it.
optional I find annoying, it's just a pointer to a null and I have seen
opt.get().doThing() cause npes just as often as codes that allows returning null to mean "nothing here yet" .
I don't see why null matterers if you have Java's level of control over pointers, I.É. You can't find the value, you can just compare it to null. If your language can convert null to zero and play with it. Fix that first: then null is a better optimization that having one more level of Indirection for every pointer.
Failure to apply "principle of most favouravle interpretation" perhaps.
If you don't understand something, to follow the principle; presume the best possible interpretation and then ask for clarity with that in mind.
If you ask and presume the worst the responder naturally is on the defensive, thus conflict.
You are probably trying to reinstall windows on a computer where windows came preinstalled and trying to install Linux on a pc where Windows came preinstalled.
For a fair comparison try installing windows on a computer where Linux came pre installed é.G an owrt router or android phone.
Yeah you wonder if any one at Intel would think like the Reg article.
Probably the decision making process will be more like...
First in first out, unless the product manager plays golf with the C level manglement or its on the up slope of the hype curve.
Then pay some hipkid to write marketing blurb to explain the decision.
It's amazing how big corps can be suckered by hype and fail to do the numbers, even when doing the numbers is literally just a case of asking someone in the same company.
"Secure" does not mean the owner of the laptop can't change it. That is "control" (by a third party) .
Don't mix the concepts.
Not having access is loss of "control". If anything it's insecure.
If you throw your laptop into the ocean its not "more secure": you have lost access, and lost control.
Not being able to choose your kernel will never be "more secure" that's marketing nonsense. Someone else is choosing it, and you are being stitched up.
If you cant advertise your own free services within your own free tools we are going to have to ban menu options that introduce you to new features, and welcome dialogs.
A "careful where you go with" that perhaps is in order but nothing more IMHO.
Canonical have to be able to advertise themselves in Ubuntu or there will be no distros that work like this. If you don't like this model use upstream Debian.
N.B. Its piss easy to migrate code off github.
To set up a git server is literally
ssh myserver
git init
If anyone wants community tools and pull requests go to gitlab.com.
N.B. can install gitlab locally too.
If you have deep embedded you whole private company, and all your private code in Microsoft's github... Get out ASAP.
Github only makes sense because it's the biggest community, hosting _private_ code since Microsoft sell out is just plain stupid IMHO.
You might think nobody got fired for choosing github, but check yourself, lots of people have been fired for accidentally exposing secrets in github repos because devs were too lazy to run
git init
Re: "Would that be fair use? It's not clear. " it's very clear, it's written in the license that by law should be published along side my code.
Anyone who really thinks publishing = giving away free has never read a book or watched a dvd.
This is "git"hub, Linus should step up and claim copyright infringement of git itself.
It's not been tested, but it would interesting what punishment a judge could deal out for blatant copyright infringement on such a massive scale. They have breached a million licences in one fell swoop.
Microsoft have illegally copied my software, I want to see them punished.
I moved most code off to gitlab as soon as Microsoft took the reigns. It was clear they would fsckup github the moment it was announced.
You are presuming that the coders who write rust dont/can't write C/C++, I'm not sure if that is realistic. I doubt many if any rust coders started with rust.
Rust and C integrate nicely, you only rewrite what you get benefit from rewriting.
There is evidence that rust is a fast language to write code in. I read an article recently by people that had ported to rust (nb coders were competent in more than one language and rust was new to them) and what pleased them most was the speed with which ocode could be added.
I find that speed of writing code is directly proportional to how far forward you push errors. If its pre compile time or compile time it's almost always faster to write such code than code that can only be tested when it's compiled and running.
There are also programmers that get paid no matter what, and closed source programmers who know no one outside the company will see their code.
I find a lot of OS code decent quality, not because 1000 eyes have fixed the bugs, (most projects have one or a few core committers) but because 1000 eyes will look at your creation and offer you a job if they like it.
Rust has lots of target architectures. Not sure what you are looking for. But I can imagine no-one makes a chip without C support so no lang will likely match C in that regard for a while.
Rust programs are larger generally due to how generics are duplicated so rust may not make sense where memory is limited.
Rust encourages a coding style where errors are ignored [citation needed]
I think most would argue the exact opposite, many errors are impossible to ignore in rust, and warnings are clear and can't be resolve with //ignoreme statements.
There are many that argue exceptions _are_ ignoring errors + gotos. And many C++ frameworks that don't use them and have C style error handling.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
