Posts by Ken Hagan 8168 publicly visible posts • joined 14 Jun 2007
"Make the UI common across all platforms."
It is far more useful to make the UI conform to the idiom of the local platform. That's what it is running on, after all. Of course, it's hard to say what the idiom of the local platform *is* on most desktops these days, since every half-wit programmer and his mate seem to feel empowered to re-write the rule book for their app because their app is "special".
Earth calling half-wits. No it effing aint.
I assume IE6 runs on Server 2003.
Remember, just because the consumer/cheap version of the OS has gone out of support doesn't mean that MS aren't still publishing exploits (er, patches) for the identical-codebase-but-more-expensive server version.
In fact, one way to get around XP's demise would be to find (if you can) someone who would sell you a licence for Server 2003. That, of course, would set you back a few hundred, but the possibility means that MS can't charge more than "a few hundred" for ever-extended support for XP.
"BTW, isn't the "Heartbleed" problem also a "use after free" (whatever happened to "uninitialized variable(s)")bug?"
It's been several days, but not as I recall. Heartbleed was failing to sanitise external input and consequently exposing a load of memory. It was made worse by the fact that the OpenSSL allocator didn't overwrite-on-free, and so the memory was potentially "interesting".
Overwrite-on-free is trivial-to-code and fairly inexpensive. Its primary purpose, however, is not to render buffer overruns less interesting but rather to make use-after-free much more likely to be fatal. Bugs are therefore caught during development rather than three years after release.
And regarding the "uninitialised variables", that's arguably the complete opposite problem: use-before-allocate. I say "arguably" because although in C initialisation doesn't exist and allocation is considered complete when uninitialised memory is handed to the application, most other languages try to ensure that something like zero-initialisation happens. Again, it is trivial for a debug allocator to ensure that insane-initialisation happens by default and so any bugs in this area show up during development.
Without wishing to slag off Microsoft (coz others have already done that for me) it *would* be interesting to know just how bugs of this nature are making it into the current release of IE, a decade after Microsoft's big splash about secure software development. In the case of OpenSSL it was because they made a conscious decision to bypass all the help that might have found them sooner. With hindsight, that was such a bad decision that OpenSSL may not exist in a few years time (having been replaced by its fork).
In IE's case, no "fork" is possible, but we're long past the time when you had to run IE because most websites didn't work on anything else. Alternative browsers exist and end-users ought to be asking whether IE's development practices are up to snuff.
Edit: In the context of "uninitialised variables" it is perhaps relevant to note that Microsoft's C++ compiler has a long-standing bug in *failing* to initialise built-in types in scenarios where the standard requires it to do so.
"What made the Mac first and then Windows platforms users liked was exactly a uniform UI among applications letting you to start easily even with a new, unknown one. The days of "I will design my own UI and you have to use it" under DOS were gone, but not everybody understood it."
Ah! Those were the days. We used to have UI standards, you know. Everyone had to follow the rules or face ridicule. Applications that maximised themselves on startup were just rude. Putting a green tick on your "OK" buttons was considered poor taste. Failing to define keyboard shortcuts and a sane tab order for all your dialogs was shoddy workmanship.
Nowadays, of course, the youngsters don't even *have* keyboards, or even "OK" buttons in some cases and applications don't run in any mode *except* maximised.
TIFCAM they call it. Disgusting, I call it. Wouldn't have happened in my day.
"The patent does say how the pulse is taken, essentially they use a "difference amplifier" to filter EMG from ECG and time the ECG."
Well that can't be relevant because using a difference circuit to extract a small signal from a large background has prior art going all the way back to the early 19th century.
"We tweak our cloud code every 16 seconds – and you?"
Am I the only person who reckons this is something they should be keeping quiet about? What's a tweak? Does it mean they are finding bugs every 15 seconds? Even if these are features we're talking about, doesn't it still mean the behaviour of the system is unreproducible/unpredictable on timescales longer than 15 seconds? Is that a good thing?
"But whoever okayed the patent needs a good talking to!"
The patent was okayed by the several hundred cretins who passed the law saying that the USPTO should henceforth grant *any* patent which is accompanied by the paperwork and the fees, leaving it to the courts to decide whether it is valid or not. The situation won't improve until people stop slagging off the patent clerks and start pointing out that the entire system is broken (in favour of the lawyers, natch).
Frankly I'm amazed that we're only up to "US Patent 8700060".
About 25 years ago, in a lecture that had strayed onto the subject of Dark Matter, our prof suggested that the true explanation might not be the various forms of exotic, supersymmetric or wacko particles that were then in vogue. It might just be a lot of bog-standard matter, too cool to see. I think he was semi-serious. This is the sort of stuff he had in mind, but I don't know how common these objects would have to be in order to make the numbers work.
At 3-10 times the size of Jupiter, I imagine it is a gas giant.
Lord Kelvin estimated that Earth's "heat of formation" would have taken about 100Mya to wear off. A rocky planet 3-10 times the size of Jupiter would have a surface area to volume ratio many times less than Earth and so would presumably cool more slowly. I think the surface would still be molten.
For a planet, gravity also releases gravitational potential energy and the gases are mildly radioactive. These are certainly reckoned to be the important factors for Earth (http://en.wikipedia.org/wiki/Earth%27s_internal_heat_budget) and are presumably even more important for a gas giant because gas is a rather better conductor of heat (via convection) than solid rock.
"That, my man, is because of the USPTO, which simply accepts anything written on a napkin if it comes from the Right Companies."
Or indeed, the Wrong Companies. I believe the law is that they'll accept anything written on a napkin, period. The effect, as we can all see, is that patent protection is increasingly hard to achieve in the US for genuine inventions. Ironically, this probably means the current patent system in the US actually violates the consitutional demand for such a system to exist.
One day, someone will try to argue that either in court or in Congress and the whole house of cards will come down.
BBB- and presumably headed downwards if Russian businesses are cut off from the internet.
Yes, there's a lot of gas over there but guess what, there's a lot of shale elsewhere that might come on stream in the near future, especially if Putin's friends decide to hike the gas price. The same probably goes for most other primary resources: Russia can either continue to sell at the world market price or it can voluntarily send its *own* economy into a nosedive. If it wants to ever be anything other than a primary producer, it needs to develop manufacturing and service industries and in the 21st century that is not compatible with firewalling the entire country off from the rest of the internet. You might as well cut yourself off from physical transport networks, or the postal service, or international finance.
Similar advice, of course, applies to China, whose economy continues to grow as long as it sells its own people down the river, and stops growing as soon as it tries to cash in (*) any of the benefits of being an economic giant. (* like, raising living standards)
The other "Tiger" economise of Asia learned this ages ago. Growth was phenomenal whilst they were playing catch-up. Once they caught up, they discovered that further growth was as difficult for them as it was for us.
Is your employer aware that s/he is paying you for a task that the rest of the world automated several decades ago?
Assigning IP addresses is the "job" of the DHCP server. Remembering them is the "job" of a DNS server. Seeing them is the "job" of the APIs in well-written software. Typing them is no-one's "job".
"The only other way would be to have your own unique domain (tomshome.co.uk) and uses sub domains I guess."
Um ... yes. They thought of that 30 years ago and so DNS is a hierarchy. That's exactly how you are supposed to do it. Only a complete moron would try to solve the name shortage by inflating the top-level domain. Oh wait...
What *is* this fixation with literal IP addresses?
Unless you are configuring a router or a DNS or DHCP server, you should never even *see* an IP address, let alone have to type one in or remember it. If you have some other network software that regularly throws literal addresses in your face, report it as a bug.
Even if you *are* setting up such a machine, you'll always be using the same prefix (yours) and the double colon notation spans the middle ground. The bit you have to deal with manually is the final hex digit or two.
For domestic customers (and small businesses, actually), you don't even need to do that. Your ISP will deliver a prefix over the wire and your router and devices can all do the right thing without any configuration at all.
29 is old enough to "get" MC, but you need to have started your family in your late teens. I don't know the actual stats, but I'm guessing that teen parents aren't a big part of the El Reg demographic, so you've probably got a few years to wait.
Joking apart, Minecraft has much of the same appeal as Lego, but is a lot cheaper and truer to the original blocky ethos of the latter. Making blocks smaller would make building anything more tedious so it might actually count as a backward step.
"I am appalled at the likes of C++ or Java where, it seems, none of us can master even the full semantics of the basic language"
In fairness to the C++ guys, the worst of the complexity results from a sincere attempt to actually describe and then remain compatible with the C subset. In no particular order, C's integer types, promotion rules, decay of arrays to pointers, lack of initialisation guarantees and (until recently) lack of a memory ordering model, have been the bane of anyone who actually wanted to write clear and safe code. Classes, namespaces, exceptions, templates and the like are pretty damn clean in comparison.
"(whoops not call it that any more)"
Why ever not? :) As far as I'm concerned all the "debate" about what to call it is irrelevant. It is "Windows 8 with the latest service pack" and anyone who hasn't got the latest service pack running can whistle for support. Funnily enough, that's exactly the attitude of Microsoft, too.
You can start shouting about a "new version" when it is chargeable (and, consequently, not everyone can realistically upgrade and so software vendors actually have to support both platforms).
"Data retrieval latency is orders of magnitude slower than memory. We're talking milliseconds compared to nanoseconds, a million-fold difference."
Good luck getting nanosecond latency out of the terabyte-sized memory mentioned in an earlier paragraph.
On a CPU running a few GHz, you'll get nanosecond latency out of your L1 cache. By the time you are hitting DRAMs or flash, the latency is more like microsecond. You've lost at least two of those orders of magnitude, maybe three. On the other hand ... that still knocks seven kinds of shit out of a disc and into a cocked hat. Back on the first hand, a decent disc cache subsystem will have delivered most of that performance already, even on DBs that are slightly too large to live entirely in memory.
So it will be interesting to see if this actually makes any measurable difference.
"In the UK, it emerged that Prince Charles actually has special powers, largely secret, to lobby and veto policies by the democratically elected government."
I call bollocks. If these "powers" are secret then they don't exist. Logically, the act of using them would require that they be made public, or else no-one would know what they'd been compelled to do against their will. Since that hasn't happened, we can conclude that they haven't ever been used. They are a figment of the Graun's over-active imagination.
It is true that Chaz has the ear of ministers, like many other lobbyists. However, the blame, er, responsibility, for the actual decisions rests entirely with the ministers involved. That's why we spit contempt for the ministers whenever they roll over for the lobbyists. We don't say "Oh, you cruel lobbyist forcing the nice minister to be a complete pratt.". We say "You complete pratt, listening to a pathetic lobbyist.".
And then we vote them back in for some reason, but I digress...
It means the waiting is over. We now *know* that Microsoft's new CEO has no more of a clue than the last one. Win9 will be more window dressing, the next version of SQL Server will be a subscription model with all your data held in the cloud, and there's going to be a major new platform announcement as they reveal "WinBS", the successor to the legacy WinRT platform.
"How the heck do you expect the NSA to find every security flaw before the rest of the entire planet?"
I don't, but...
There are relatively few SSL suites in widespread use and pretty much all secure communication on the internet is built on top of them, so they are pretty important. OpenSSL happens to be open source, but that's probably not an issue since I'm sure the necessary arms can be twisted if the NSA want a look-see at Microsoft's crypto libraries. If the NSA, with a budget in the billions, doesn't have a team poring over these suites then someone needs to have their employment contract reformatted.
I expect that team to find a buffer overrun vulnerability in a codebase that lies square in the middle of their competence with a couple of years of it being published. Whether that is before the rest of the world is another matter entirely. I also assume that several other nations have teams doing much the same, so they might get there first.
"As is becoming increasingly clear, the NSA has done more economic harm to the U.S than any foreign actor in recent history, aside from perhaps China."
I don't wish to be too cynical here, but in peacetime it is generally true that the main damage to a country's interests come from the incompetence of its own government. They have so much more power than any other actor and yet they are subject to all the usual human frailties and incompetence.
It is "elegant" in the sense that it does not adversely affect clients that send well-formed packets, it will never (for sufficiently small values of packet length) crash the server, is pretty unlikely to do so for larger values, and you can just set up a server farm hoovering up data from zillions of targets 24/7 for a few years and see what turns up. It costs you nothing more than the leccy bill.
Given their resources and their mission, they (and like-minded agencies in other countries) ought to have people reviewing the changes being committed to OpenSSL, as they happen. If they didn't spot the flaw within a week or two of it being committed then they should be asking themselves why.
"NSA isn't in the "protect your bank account[...]" because those functions aren't in the national interest no matter how important we think we are."
You must have missed the financial crash a few years ago. A way of pulling down small numbers of bank accounts is not a problem. A way of hoovering up credentials quietly until you have a million or so accounts that you can vaporise in one night of action would be untargetted but definitely a threat to the nation's well-being.
It is no secret that the NSA exists and has a massive budget. Any moral outrage about its activities should either have been consistently expressed for the last few decades or, if only recently felt, should be based on revelations concerning who they target rather than how they do it.
I don't have a big problem with the NSA using a 0-day to spy on (say) North Korea.
"They are either unique or they are not. Stop mangling a very useful word."
I sympathise, but I thought that "not as unique" was rather appropriate. It will, after all, come as a great surprise to those concerned to discover that they are replaceable. One must break these things gently, even if it pains your inner linguist.
...let me be the first to point out that (with a round-trip latency of just a few seconds) only a complete cretin would populate a moonbase with fleshies. They need air, food, water, healthcare and a psychological need not to be boxed up in a confined space for months on end. You want drones.
"a serious beating with a Clue Stick"
Would a Clue Fork do? Based on what I've learned in the last week, I wouldn't be surprised if OpenSSL wasn't the only game in town in twelve months time. They could start by fixing the bugs that prevent the use of the standard allocator.
"How about bounds-checking in hardware?"
To be effective in this case, it would need to have byte granularity and be capable of tracking millions of separate allocations. Hardware bounds-checking at page granularity works well for keeping processes off each other's toes. It's impractical for tracking the millions of tiny allocations that a large server might have in play at any given moment.
On the other hand, there are languages that automate such things. They are frequently able to prove the correctness of a particular access at compile time. Where a run-time check is needed, memory latency and out-of-order execution often means that the check costs no time. Either way, these methods are practical at whatever granularity and whatever scaling you care to mention.
"No, the problem is C. In a reasonable language, declaring an array of byte data[P] would result in an *empty* array of bytes."
and that is what would have happened in OpenSSL if the writers hadn't chosen to write their own allocator. The most fascist bounds checking language out there won't help if you write your own allocator on top, particularly if you write one that permits use-after-free.
Perhaps working on cryptography software requires a particular (and rare) combination of skills. It's all very well pointing out that this bug is a novice error, but when it is buried within a lot of code where even fixing valgrind errors has catastrophic consequences, most of us are too aware of our own limitations to even step forward.
"... D. It's a lovely language - essentially a rebuild of C++ with an "if we knew then what we know now" approach."
A bit like C++11 then. Both would be perfectly reasonable replacements for the C that (inexplicably to my mind) appears to be the preferred choice for several rather important FOSS endeavours. Seriously guys, it has been a quarter of a century since we learned how to make C safer without any loss in performance (or one's ability to twiddle bits or map brain-dead structure layouts). Memory management in particular is a solved problem.
"I can't imagine any government agency trying to support an OS themselves."
The OS almost certainly isn't the problem (and if it was then the USG already has the source code and could probably use its waiver on copyright protection). The problem is probably half a dozen "critical apps". The company may have ceased to exist, or failed to keep the source code, or simply be too incompetent to product a working Win7 version. In those cases, source code escrow would be a useful insurance. We're probably talking about fairly small amounts of code, too, compared to an OS.
It's because it serves no purpose to do so.
An OS will certainly zero pages before giving them to you because those pages could have come from almost any previous process and the security implications of that have been known since the 60s. However, all sane runtime libraries ask for big blocks from the OS and then implement their own sub-allocation scheme on top. Doing it in-process is a big performance win (because you don't have to cross privilege boundaries) and omitting to zero the sub-allocated memory in your own address space is not a problem because it was already visible to any thread in your address space. It's not a problem until you then squirt the dirty memory out of a socket.
Yes, it could have been avoided by using calloc() rather than malloc() everywhere, but it could also have been avoided by sanitising your inputs before responding to them. The former would pointlessly double the number of writes to memory. The latter is simply "correct". My vote goes for the latter.
Note also that debug versions of malloc nearly always do pre-fill the memory (and the matching version of free post-fills with a different pattern) but this is *because* it is pointless to do so. Or rather, because it bloody well ought to be pointless and therefore doing it is a simple way of flushing out a certain class of bug.
What would you bother? ext2 is adequate for most purposes and already exists. You'd need to bundle the Windows ext2 implementation as part of the "PC tools" for your phone, and persuade your customers to actually install those, but once you've done that you've broken the FAT licensing gravy train forever. *That* is what Microsoft are worried about.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
