All a bunch of bullshit invented to sell drugs that don't even WORK.
So the conditions are fake and the drugs don't work??
I'm curious.... how would you know if the drugs were working?
Of course it will alternate even and odd, the article is incomplete...
I don't think it will, at least not daily. That would result in a weird game of musical cars. You could drive somewhere one day and then have to wait a day to drive back. Annoying as it is if you have the wrong plate, it makes more sense not to alternate (at least not often, and hopefully the ban won't be around that long anyway.)
I wonder if they are banning electric cars with even numbered plates. I'd love to see the reactions to that.
Why not? You allow only half the vehicles on the street today and the other half tomorrow. You have halfed your traffic and brought your pollution levels down. It is quite simple to enforce by number plates. Petrol today and diesel tomorrow on the other hand is difficult to enforce, makes no sense.
I agree, but there's nothing in the article to suggest that it'll be half the vehicles today and the other half tomorrow. Instead it says "Only vehicles with numberplates ending in an odd number will be allowed to drive... for a few days" You'd think it'd be odd numbered plates on odd numbered days and even plates on even days, but that's not what it says.
But come to think of it, that'd be a little weird: you'd be able to drive your car into the city on one day, but wouldn't be able to drive it out the next. You wouldn't be able to go anywhere overnight, you'd have to wait a day for the return trip. They're using check points to stop cars from entering the city, but presumably they won't stop anyone leaving.
If you're already in the city, just plead ignorance; who watches the news anyway?
I agree overall with your comment, but I think UTF-8's backwards compatibility with ASCII was genius and is the reason we have as much Unicode support as we do today. I consider UTF-8 to be one of the best hacks of all time. Without it, the software that existed at the time would have had to be thrown out or re-written. The fact that software can (often) process UTF-8 without even being aware that it isn't ASCII was exactly what was needed to get Unicode off the ground. UTF-8 allowed Unicode to be adopted incrementally (especially by Unixes, which were much slower to adopt any (universal) international character set than Windows was).
Sadly, not everyone is as brilliant as Ken Thompson, so the UTF-8 encoding didn't exist when Unicode and ISO 10646 were first created. If someone had thought of it just a few years earlier we probably would have used that for nearly everything, and your second point would be irrelevant.
But by the time Unicode was even a thing, a lot of the software industry was already invested in ISO 10646, specifically UCS-2 (notably Microsoft and IBM, but plenty of others) so unless you think excluding IBM and Microsoft (in 1990!) would have been good for the widespread adoption of Unicode, the designers had no choice but to have multiple encodings.
Ironically, Linux and Apple were able to chose the (arguably much better) UTF-8 encoding only because they got serious about adopting an international character set several years later than Microsoft and IBM did (call it second mover advantage.)
So I couldn't call those mistakes. More like "historical accidents", just like most other bad designs we have to live with.
Your third point is just a face-palm, I agree.
The GP was right; for a right-wing nutjob he makes a lot of sense. I've been saying the same thing for years, nobody listens.
You're never really "locked in". All that is really meant by that is that there is a cost to moving away from some external dependency, and there is always a cost. Every external dependency a project takes on is "lock in." That includes the operating system, programming language, third party libraries, and everything else that isn't part of the project itself. You can try to minimize it with abstraction layers, but that has a cost too, and it is often paid unnecessarily when the dependency never needs to be removed or changed. Or you can also try to minimize it by using the good old advice to avoid nonstandard/non-portable extensions. But that has a cost too when the nonstandard extension does exactly what you need and it's expensive to do yourself. That's just wasted effort if you never actually end up needing to switch.
The only good advice is to choose your dependencies carefully and if necessary have an escape plan. (But don't spend too much effort on the escape plan unless there's a high likelihood you'll actually use it.)
That's only true if you want to run controls that were written for windows. If COM and OLE were supported on other platforms, then presumably people would write COM/OLE components for those platforms, and those would run fine on their platforms.
Back in the 90s, there were some other systems that supported COM/OLE (IBM and Sun Microsystems for example.)
CORBA is practically the same thing, and is available everywhere. The problem with CORBA is that is a typical design-by-committee mess. It ended up way too complicated, even compared to COM/OLE.
The problem that COM and CORBA both solved (or at least tried to solve) still exists, with no commonly accepted solution. The "standard" binary interface between components on every single platform is the C function. That's the only code that can be called directly from (almost) every language without creating "bindings". Not even C++ code from different compilers can be mixed in the same program, because C++ doesn't define the binary interface.
Something like COM or CORBA is still needed. If we had it, and it was universally available, you could expose more than just C functions at the binary level (without bindings or without recompiling everything).
Because of all the years of bad press, nobody is going to believe it, but COM was and is a good idea, and it's completely unencumbered by patents or licensing issues. Being able to combine components written in different languages (or even just different C++ compilers) is a good thing, and is too complicated without something like COM.
I've written many ActiveX controls, some for use in a browser, some not.
At no point was I required to sign or agree to a license to do so.
With requiring a license he was talking about creating the ActiveX runtime environment for a web browser.
No license is required for that either. All ActiveX is, at heart, is a hierarchy of C++ style interfaces (classes with nothing but pure virtual functions) rooted in a single interface (IUnknown), together with a handful of global C functions (e.g. CoCreateInstance). It can be supported on any platform as long as the C++ compiler implements virtual functions with a pointer to a vtable at the beginning of any object with virtual functions. That's every major compiler on every major platform. Actually you can do COM "manually" in plain old C too, so you can do COM anywhere with a C compiler. Put pointer to an array of pointers to functions (the vtable) at the beginning of a struct, if the functions have the proper signatures then the struct is a COM object.
I know this because I've also written many ActiveX and COM components, and ported COM/OLE/ActiveX code to Linux and OS/X. Generally the problem with implementing ActiveX on other platforms has nothing to do with ActiveX itself. The problem is that virtually all ActiveX components are written for Windows and make Win32 calls.
Unicode is sort of complicated, or at least it's more complicated than might be expected. But the problem with Schneier saying "Unicode is too complex to ever be secure" is that he might as well just say "programming is too complex to ever be secure." Sure, Unicode is a little complicated. But it's hardly the most complicated thing you'll ever have to deal with as a programmer. If we can't even get that right, we might as well just quit.
Stop the presses a bug found in a large complex program.
It's not "a bug" in "a program". It's every major browser. And it's pretty much like this every time they do pwn2own. If a group of hackers are able to bring down every major browser with previously unknown* exploits every year just for a chance to win a laptop, what can better motivated (financed) groups do?
* unknown to the browser developers anyway... 17 seconds to pwn IE, yeah right... like they say on the cooking shows "here's one I prepared earlier"
The last thing Jersey needs is more car dealerships and lots. So I can see the numerical limits as having some merit.
Have you ever been to a Tesla dealership? They are nothing like typical dealerships. They don't have sprawling lots full of cars. They are small, typically in pedestrian friendly areas nowhere near other dealerships, and have just enough cars that you can look at the models and options, with a few more cars for test drives. They're more like a retail store than a dealership lot. Here is a blog with pictures of dealerships around the world.
Each car is built to order, and you come pick it up at the dealership or they deliver it to you. I suspect the limit is a compromise with opponents of Tesla's model, not anything to do with too many dealerships.
Most companies would not keep any developers over 50 on staff.
It's their loss. Most companies are horrendously bad at making software. The ones that are very good at it know better and have lots of older developers on staff.
And the research shows they're right:
Older Is Wiser: Study Shows Software Developers’ Skills Improve Over Time
My experience tells me the same. Most of the really good software engineers I know are at least 40, many are much older.
Go ahead, throw 'em out and get some newly-minted CS grads. Someone with some sense is going to get a great hire.
If at first you don't succeed, you must be a programmer.