So... they will have to reboot daily from this point onwards ?
And wait for extra 15 minutes before leaving work ?

Oh god. Bring back patch Tuesday.

Thank you Google, for your inflexible 90 day deadlines that expired a couple of days BEFORE patch Tuesday.

You can bet this came out directly because of those issues that Google published a few days early This way Microsoft can have patches ready ahead of time before the deadline, instead of having to wait for patch Tuesday.

Google: FYI, Windows users probably make up the bulk of advertising revenue. Having Microsoft release shoddy patches early to meet your arbitrary deadlines would mean more breakage and therefore less people to sell.

If the hardware is still fully operational after 20 years in a hostile enviroment like an oil rig I'd say its anything but "crud". It was probably some of the best kit on the market.

Yeah, but it's now unsupported kit and who knows if there are rollover issues? It already ran 20 years, so it's conceivable it will run another 20+ years and hit the 2038 bug, then what? And catching this bug is a lot more subtle than the y2k bug.

We've already run into rollover issues - on an old processor board that people are still paying us to support (it was over 10 years old when it was designed, and practically every component on it is EOL'd except the Ethernet chip. Fortunately it's the Ethernet chip that basically is the problem). Considering the volumes and the customer involved (they only really come back to us annually) we never bothered updating the software and now what were automated tests and provisioning tools don't work anymore so when we repair and reflash them, it has to be done manually because the automated tools don't work anymore. It's not worth the time to update the tools (too little money, too little quantity, too infrequent).

Defining programming ability is a real challenge and the definition probably varies based on what is being programmed. I had a teacher who defined it as being able to complete a task in as few lines of code as possible. OTOH, is it worth spending 2x the hours to get rid of 2 lines of code when a quicker solution works just fine?

And that is the crux.

Lines of code is already a poor measure since you can take a few lines and turn them into one giant compound un-analyziable hard-to-debug line, or leave them in several lines and save yourself a lot of trouble in a month's time when it comes to revisit the code and be able to pick it up far quicker.

I mean, if we take bubble sort, and inside it's core is a routine to swap two variables. (Well, I guess most sorts have this property). You could save yourself a line of code by not declaring a temporary variable and just do manipulations on the two variables you have to swap them. But is this better than using a temporary variable and using a bog standard, trivially analyzable and idiomatic method to swap the variables?.

Similarly, there are "clever" ways of doing things that may rank higher up on the "skill" level, but make it a PITA to analyze later on when you're either debugging some future issue or just trying to figure out what you wrote a month or more ago.

So yeah, measurement is hard. Is someone who takes the easier route but writes easier to analyze code less skilled than someone that could write the code in the fewest lines possible, but the lines are horrendously complex and difficult to analyze or debug? The code is clever, fast, and does work...

"Perhaps it was written by him in his spare time". OF COURSE it was written in his spare time. His a prime minister, he doesn't write code on the job. What comments do you want? The code is simple and obvious. What data structures to explain? If you are too stupid to understand them immediately, then you shouldn't be programming. What lack of error checking? What scenario do you suggest where error checking would help?

Easy. What does (x & -x) compute, off the top of your head?

There's so much bit-twiddling there that it's confusing and does boggle the mind. It's clever, yes, but guess what? Clever sucks. It's the code you get from prima donnas who don't expect to maintain it. Heck, someone posted a link to bit twiddling hacks on a Stanford server - it's a lot of elaborate code that's non-obvious (and even that hack isn't actually in the list, interestingly).

And yes, error checking. Sure it's a simple app that doesn't need error checking, but it's useful to have common error checks put in - I mean an 80 char buffer for a 9 char string is not an error prevention. Using scanf() with a field width specifier is dangerous - you might as well just use gets() and be done with it - you get the same result. And we know WHY you don't use gets().

You seem extraordinarily proud that he might code something up like this. Perhaps. All I say is that perhaps it isn't 100% original code, he didn't sit down one day and say "I can't solve this Sudoku, so I'll write my own solver" and crank that out. It almost seems like someone provided basically everything and his "contribution" is he typed it in.

There are enough fancy tricks in there coupled with a lot of interesting issues that I would call it as perhaps a bit more effort than what Obama did, but not by much.

And comments? Yeah, they're important, especially assuming it was done in his spare time. I mean, if he's doing it on and off, I expect him to forget. Anyone who maintains software knows after a month, the code you wrote might as well be written by someone else.

Yes, it's possible it's 100% original code that he cleverly wrote a few years ago, in which case, yes I apologize. But it reeks of a lot of things that seem far outside the realm of common domain knowledge amongst developers (nevermind high-ranking government officials) that either he had a lot of help, or someone wrote 99% of the code, and he finished it off, kinda-sorta like Obama's JavaScript thing. (And given it IS Singapore, I expect the original developer to keep silent on the matter for many reasons).

I don't know.

The code resembles something you expect from a first-year programming student - there's an input buffer overflow bug waiting to happen, the array size is odd (80 byte array? why? scanf() is still called without a field length specifier, and you only use 9 of those 80 bytes in a normal case).

Perhaps it was written by him in his spare time. Or maybe it was like Obama where the base of the code was already provided and he needed to fill in a few things.

Plus the general lack of commenting, explanation of the general data structures used, or algorithms. Maybe even ding points on practically everything being a global variable.

Either he was learning to program, or someone basically told him what to do which explains the lack of error checking, the lack of comments, and the use of globals and he was a coder-monkey and not someone who develops software who took a set of requirements and created something from scratch.

So, props for the effort, but is it really original work, or was there someone else at the keyboard helping him along?

I only wonder why they only tested android apps, and left out IOS apps. Without this comparison, the first paragraphs of the article, blaming the tracking and ads on the openness of Android, is little more than wistful thinking.

Well, if the apps are just ports of each other, then it's exactly the same.

However, if you want to make money, the business models on iOS and Android differ. On iOS, selling a paid app is a really good way to make money - iOS users will pay for apps.

But on Android, paid apps are put under a huge disadvantage compared to free apps, especially since Google Checkout isn't available in a lot of markets because of regulatory or other issues. Compare paid versions of iOS and Android apps, and iOS pretty much dominates - despite Android's far far far greater marketshare. So if you're a developer, you're going to make your app ad-supported. Not only is this the only business model that works on Android, it's one where you can easily make way more money than iOS.

Even ad-supported apps on iOS are under disadvantage - Apple has restricted what you can do to track users, for example. If you try to get the UUID, your app gets a unique per-app one, so even if two apps use the same ad networks, they appear as two separate users. And an iOS user can reset them at will. And Apple asks you why you're getting the UUID, as well. Also there are restrictions on accessing contacts, location, photos (which can proxy for location).

Hardly. AirBnb and PayPal are both good examples of this sort of thing. PayPal got raided a lot and got sent C&D letters by various state regulators when they were rolling out across the USA. Eventually they had to sell to eBay (their primary competitor) to get enough money and political immunity to survive. There's a book about it called the PayPal Wars that goes into more detail on this.

eBay and paypal were never competitors.

eBay and Paypal are synergistic - eBay needed a low-friction payment platform. Prior to the Paypal acquisition, an auction listing might only take money orders for payment (thought many sellers took Paypal because it was way more convenient). And money orders in the age of the Internet really goes back - I mean, telling the buyer to go to a post office, buy a money order, then stamp and send it off the seller and hopes it all goes alright? If you were a buyer out to screw the seller, you could win a bunch of time-sensitive auctions, then hang them up for weeks waiting for money orders. (You have to remember they will take roughly a couple of weeks for the buyer to get one and mail it off, and perhaps you can claim "lost" and take another couple of weeks). If it was a time-sensitive material, that could span a couple of months and render the product worthless.

Then there was the seller who might receive and claim it as not paid still.

Paypal offered something no one else did (or still do) - the ability for Joe Random to take a credit card payment irregularly. Merchant accounts are expensive and often have conditions. Paypal did not - if you only did 1 $100 sale in a year, that was fine for Paypal. Most merchant accounts would've charged you several hundred dollars if you did that. And credit cards ensured payments could be sent instantly and quickly, more in line with traditional online shopping.

Sure it probably took eBay's might to sort out all the financial and banking issues, but eBay and paypal are not competitors. They're not even just two random companies - they're companies that realize each has a product or service that works really really really well together. Even post eBay/Paypal split the relationship is more than that of two companies.

Actually, I think you're speaking for yourself when you don't have a clue what I have running in my home.

8 kWh computer (just mine, not including the other laptops and my SO's own computer.)
3 kWh in LED grow lights.
7.2 kWh A/C (this is California.)

And so on...

And you are the 0.05% of households. Tesla's solution is basically the 95-99% of use - the average home really is budgeted to use 1-2kW average over the entire day.

Most people don't use 4x 2kW supplies, because running 4 20A circuits for a computer is unheard of in a residential setting. Even the modern building codes which dictate 1 20A circuit per outlet in the kitchen often only provide 4-5 outlets for the entire kitchen (besides regular 15A circuits for the microwave and fridge, and 240V circuit for the stove). That's because people have a nasty habit of plugging their toasters, kettles, and other appliances in at once.

Why does every solution need to fulfill oddball out of the way requirements? Just like an electric car might not work for 10% of the driving population makes them completely unusable? Or for the once-a-year time you need to haul away some stuff you're willing to toss away a solution?

If that was the case, we'd all be using desktop PCs because laptops compromise too much, tablets would be completely useless because you couldn't "create" on them, and don't get me started on smartphones - they can't run top end games or browse full websites, or anything.

Just because something doesn't work for you doesn't mean it's a stupid idea. If your needs fall so far outside the realm of average use, then move on. Meanwhile, everyone else can have their batteries that either charge themselves off the grid during off-peak cheaper times and deliver the power inside the house during expensive peak times, or charge themselves off a solar array to provide night-time power.

Cough, cough, IBM did the work, M$ just ran off with the benefits due to a very, very shonky contract.

At the time, the IBM PC project was a lightly funded "get it out there quick" project. This was IBM using an off-the-shelf processor and common every day parts to make their PC, after all. This WAS IBM, and generally NIH was verboten. But IBM needed a PC quick and cheap.

The only bit that was truly IBM's was the BIOS, and IBM figured that since DOS was tied heavily to the BIOS that no one would clone it, so Microsoft retaining the rights wouldn't mean that much since every sale of MS-DOS was for an IBM PC.

On Windows it gets even more fun. They like to piggy back spyware with cracked games. So for your unwillingness to spend $50 on a game, you have some creep electronically playing out the plot of Porky's with your PC.

Actually, not really. The games themselves are generally distributed verbatim in order to keep all the code signing signatures intact (this includes the installer). In fact, they're typically the same as if you bought the downloadable version of the game. This is handy for those of you who lose the original disc but have the keys and whatnot around. Or if it's a steam game, it keeps the original signatures as if you got it from steam.

Instead, the infected part is the unsigned code - i.e., the crack or keygen. No one expects those to be signed, so they wrap them with a dropper utility that will install the malware before running the real code.

Or, there are also a bunch of fake cracks and keygens that do nothing other than install malware.

Why would I bother with the used one?

It's actually a reflection on the odd fact that a brand new Tesla is often *cheaper* than a used one.

Yes, you heard that right - you can pick up a new Tesla cheaper - Tesla's got a continual backlog of at least 3 months or more...

I doubt it. I think it is far more likely that the pharmacy sells this information to insurance, pharmaceutical, and marketing companies. Big data is big business these days. So long patient confidentiality.

That being said, it is unconscionable how lax PillPack.com security procedures were.

Exactly.

First off - is a full name and DOB a unique enough identifier? For something as vital as a prescription, it doesn't seem like it. I would presume for patients, there's a real unique identifier involved for electronic prescriptions or using a real scrip.

The fact that there's no other identifier involved seems to imply sold records that only have your name, DOB and prescription. Not good enough to actually uniquely identify people, but good enough to pre-fill information about you, and if there's a collision, just merge the records and hopefully it'll never come up, or the user will pick the right meds (not that it matters since they still need a real prescription to get the meds).

I think what PillPack.com revealed is the extent to which your drug purchases are sold around. Though aren't such things covered by medical privacy laws?

No. This is a "What the f* were you goofballs thinking when you wrote this code? And if this is all the better you can do, what other gotchas are hiding in there?"

Well, most of the case would be that they didn't realize it might be an issue.

Early Linux suffered from this issue a lot - device drivers could not be counted on to survive if jiffies overflowed. Modern day Linux implements a bunch of utilities to compare jiffies with an elapsed time (that handles overflows), as well as starting the jiffies counter 3 minutes before overflowing so it overflows early and bugs are detected.

Of course, in this case, it was discovered in a lab setting - not only is it unlikely to happen in the real world (no, making a change to cause the roll over early will not happen as it turns working code into an untested state), but it also relied on someone pretty much leaving the equipment on the whole period then noticing it died.

I don't know about you, but finding out the reason why something died 250 days later is difficult and probably only was discovered accidentally because someone left it set up at their desk the whole time.and forgot about it.

Hell, it's probably a given the bug exists in plenty of other things as well, just they're normally cycled long before it's a problem and no one actually ran it long enough to test.

If you find that interesting, you may also be interested in the VMWare install script, which starts as a shell script but has a compressed binary attached to the end.

That's not interesting at all - there's something called a shell archive, or "shar" which is what it implies. GNU has "sharutils" which is used to create and extract files from shar files (or you can run the script - it IS just a regular shell script).

The benefit is, of course, you can embed a binary inside it and it self-extracts, and is transmissible over text-only media without having to use uuencode/base64 or other utility.

Of course, they aren't standard, and often are limited because they rely on external installed programs you should have in your system, and often there's version dependency on the programs it relies on, enough so that older shar files might not work on newer systems.

Or, say, Azure. It's a money maker, despite playing catch-up with AWS.

Actually, doesn't Apple use Azure to power iCloud? Rather than Apple trying to do their cloud thing themselves, they rely on a cloud provider, and the one they chose was Microsoft...