I presume you're talking about Oyster cards, and Oyster cards are RFID (the chips are from Philips, called "MIFARE"). The readers used for Oyster cards are limited to a fairly short range (so you've gotta put the card quite close to the reader) but that's a configurable parameter.
The reason they don't make the range longer is probably because it'd be too inconvenient; particularly for users of pay-as-you-go Oysters. They might find themselves being billed for journeys just from having a bus pass too near them (or from walking too close to a tube gate).
...and the doctrine of laches says that's not allowed.
They could almost certainly have asserted their right years ago. Windows Update has been around for yonks.
The software cost of Win2K3 Web Server edition (above and beyond a "free" OS; TCO be damned, the incremental cost of another server is approximately nothing once you've got a load of IT staff employed) pays for about a day of a developer's time (if he's in-house) or less if he's a consultant.
If you think that PHP's cost saving really allows you to spend much more on developers you're in cloud cuckoo land.
I am endlessly amused also by other posters' failure to distinguish between ASP and ASP.NET.
Yeah, no kidding. SFU 3.5 is free (in the only sense that's important) and has been out for a while now. That MS may (or may not) bundle it with future OS releases is neither surprising (given that SFU is the old POSIX layer done properly) nor news (given that such suggestions were mooted back when SFU 3.5 was released).
Those suggestions don't appear to have become appreciably more concrete, so really, what's the big deal here?
(in terms of product quality, not sales:p )
This doesn't seem to be anything above and beyond what iriver (who make the best, though perhaps least attractive, personal MP3 players available) have been doing for months.
The BBFC have traditionally gone above and beyond the requirements of the law; what they say and do should not be taken as a reflection of the word of law. They may refuse to grant a certificate to a film, but that doesn't ipso facto demonstrate any illegality.
Further, the obscenity laws are sufficiently non-specific as to be useless; they don't need to change the law to permit certain things being shown, because the law never specifically forbade them in the first place.
Except that my old non-camera phone is a much better phone, and I wouldn't carry around a camera anyway. Nor would most people (as amply evidenced by the fact that prior to the release of camera phones they didn't).
As such, the camera phone falls squarely into the "solution looking for a problem" category.
And even if one really did want a camera, a camera phone would be hopelessly inadequate anyway; crap compared even to a disposable 35mm camera, let alone a proper one.
Because, since XML is not a format (but rather a standardized way of creating one's own formats) the issue of "creating a format" is not solved by the decision to use XML.
What XML "wins" is off-the-shelf parsers; one still needs to write some amount of code to convert dumb XML (elements and attributes and all that crud) into something with semantic meaning to your application.
For a simple application like this it's not clear that the overheads of XML (both in terms of size, computational complexity, and programmer overhead to make the aforementioned conversion) are at all worthwhile.
Any object reference in Java is a pointer; it's why the exception is called a NullPointerException. Once one understands this, one can discard wrong-headed notions such as "Java has pass by reference", which are all too common, and all too wrong.
Java's pointers might not have pointer arithmetic (which seems to be why people claim them to be something other than pointers), but the key feature of a pointer is that it's an indirection, not that it can perform certain kinds of arithmetic. And Java's pointers are exactly that; they're pointers into the garbage-collected heap.
Hierarchical strongly typed securable storage is not a bad idea.
The registry may have been designed and implemented for storage of specific useful information which would contribute to interoperability between applications but it doesn't take a brain surgeon to look ahead and see that every screen saver, toolbar, and "neat app" author would start filling the registry full of excess junk keys that mean nothing to the rest of the system.
So? It's not meant to. If it's under HKLM\VendorName\AppName\ then it's not *meant* to be meaningful to other applications. One would have thought that the fact that it's in a location private to the application would have made that obvious.
Additionally there are more than a few ways to hijack.dlls using the registry, Back Orifice, Sub7, and NetBus come to mind.
This functionality is not anything provided by the registry (it may be stored there, but the functionality would remain the same if it were stored in a text file, no?); it's ignorant in the extreme to blame the registry for this kind of thing. It's not even clear that it's a bad thing; it seems to me that it's a feature that can be used for good or bad purposes. Much like other features, such as "running software". "The registry" has no functionality of its own; it's just a database.
That is why I blame MS for the registry. It would be a good idea if the user was consulted for every new key added. That can't be done because the user can't be bothered.
That would render it useless.
Unfettered, unrestricted application access to a housekeeping system with as much clout as the registry should plain not be possible.
It has no "clout", and access is neither unfettered nor unrestricted. Registry keys are securable objects.
Since it's impossible to secure the registry the registry never should have been implemented.
It's as securable as anything else; registry keys have ACLs, so one can restrict the operations performed on them.
No doubt you'll bleat "oh, but since everyone in Windows uses Administrator that doesn't help". This is wrong on two counts; (1) not everyone uses Administrator (2) it doesn't help, but it doesn't help if they're a regular user either. Why doesn't it help? Because as a regular user (just as with regular users on Linux or OS X) they can destroy their own data; they can run malicious programs when they log in; they can send viral e-mails; they can run spyware. None of these things are privileged operations (and nor should they be). Permissions don't help in mostly single-user client computers. They can only protect pointless things such as the system's files. But you don't need them protected. You've already got them on the installation CD. They're not the things you've invested hundreds of hours in creating.
The old Soviet Empire couldn't innovate because it centralized its decision making.
Er....
To claim that the Soviets could not (and hence did not) innovate is completely absurd. Organizations such as Electronorgtechnica (aka Elorg, to name one that everyone here ought to have heard of...) simply couldn't have existed without innovation to back them. Nor could the highly developed Soviet war machine or space programme.
They developed a lot of good hardware, and that required innovation on their part.
Centralized decision making does not mean "no innovation"; what it means is that the innovation is limited to those areas that the central decides will see development. And even then (as Elorg's most famous product shows), there was more freedom than you give them credit for.
gzip is the name of the compression format (RFC 1952) as well as the utility often used to create files using that format; as such a rewritten version is quite possible, and it wouldn't be surprising to find that the rewritten version is named something such as "gzip". And the zlib compression library itself (unlike the utility) isn't GPLed, in any case. It uses a sensible license instead. A cursory glance doesn't suggest that any of those files are from either project, however.
elsewhere
This dates back to 1999. Have there been any groundbreaking advances in the meantime?
Self-heating cans have been for sale for months
on
Self-Heating Can
·
· Score: 1
How is this better than the Nescafe "Hot when you want" cans that have been for sale for some months?
They're coffee in a can that heats itself before you drink it; they cost about a quid, a quid fifty.
I don't know if they were limited-period trials or promotions, but they were certainly for sale towards the end of last year.
Several MS representatives have referred to the CLR as a VM
And several have said it isn't.
You're wrong on the other point too. The CLR specifically supports the type system described by the CTS. IL's instructions operate specifically on those types. You can, of course, implement any set of language semantics you like, but it won't necessarily be either efficient or worthwhile. Why else do you think Meyer has cut Multiple Inheritance and covariance entirely out of Eiffel# ? The same goes for C++: only "managed C++" (C# that looks like C++) actually compiles to the CLR as a target, and guess what ? Managed C++ does not support multiple inheritance.
This is incorrect -- I invite you to actually try it out.
You can write unmanaged, unsafe code that targets the CLR. Take a look at this, if you don't believe it. A whole load of IL -- unmanaged, unsafe -- that targets the CLR.
The CLR supports a lot more than just the CTS. There is no reason for Eiffel# to restrict itself to the constraints of the CTS.
Re:Is this article acurate?
on
What is .NET?
·
· Score: 1
Perhaps you need to reread the article.
I'm aware of such languages, and I mentioned them. I'm also aware of the issues with them -- few of them can participate on an equal standing with Java (Jython appears to be the biggest exception to this), whereas the same is not generally true of the.NET languages. Only a small subset of those languages are call and inheritance compatible with Java, versus nearly all (if not all) of the.NET languages.
It's called ECMAScript, ECMA specification #262. Made by TC-39 as a vendor-neutral amalgamation of JScript and JavaScript.
TC-39 is the group now working on C# and the CLI.
Re:I honestly can't figure out
on
What is .NET?
·
· Score: 1
Er. That would be all well and good, if Java implementations weren't bug-free.
There have been bugs in JVMs. Blessed, coffee-cupped, JVMs. There will, I'm quite sure, be bugs in future JVMs. Even from Sun.
It's happened before, and no amount of "enforcement" makes people write perfect code.
Re:Classes and APIs more important than language
on
What is .NET?
·
· Score: 1
Can you explain what aspect of the CLR makes a usermode thread implementation impossible (presumably this is how Erlang's "very efficient thread implementation" works)?
Re:My first thoughts after reading this:
on
What is .NET?
·
· Score: 1
Hack your runtime to no longer care if an executable's stored hash doesn't match up with what it's calculated to be.
Slashdot Mirror
And even then there would still be security flaws. I think the saying about bugs goes something like "Any non-trivial program has at least one bug."
Only if you define "non-trivial" as "buggy".
If you're willing to discard such notions as the "inevitability" of bugs then you can find that bug-free programs aren't that hard.
I think they're RFID too. But I don't know how one qualifies as RFID. It could be completely arbitrary for all I know.
And there are worse things than living in London. Living in Edinburgh, for example.
I presume you're talking about Oyster cards, and Oyster cards are RFID (the chips are from Philips, called "MIFARE"). The readers used for Oyster cards are limited to a fairly short range (so you've gotta put the card quite close to the reader) but that's a configurable parameter.
The reason they don't make the range longer is probably because it'd be too inconvenient; particularly for users of pay-as-you-go Oysters. They might find themselves being billed for journeys just from having a bus pass too near them (or from walking too close to a tube gate).
...and the doctrine of laches says that's not allowed. They could almost certainly have asserted their right years ago. Windows Update has been around for yonks.
The software cost of Win2K3 Web Server edition (above and beyond a "free" OS; TCO be damned, the incremental cost of another server is approximately nothing once you've got a load of IT staff employed) pays for about a day of a developer's time (if he's in-house) or less if he's a consultant.
If you think that PHP's cost saving really allows you to spend much more on developers you're in cloud cuckoo land.
I am endlessly amused also by other posters' failure to distinguish between ASP and ASP.NET.
I'll bet they think "ASP is a language" too.
And India has spicy food. I know which one I prefer.
Yeah, no kidding. SFU 3.5 is free (in the only sense that's important) and has been out for a while now. That MS may (or may not) bundle it with future OS releases is neither surprising (given that SFU is the old POSIX layer done properly) nor news (given that such suggestions were mooted back when SFU 3.5 was released). Those suggestions don't appear to have become appreciably more concrete, so really, what's the big deal here?
(in terms of product quality, not sales :p )
This doesn't seem to be anything above and beyond what iriver (who make the best, though perhaps least attractive, personal MP3 players available) have been doing for months.
The BBFC have traditionally gone above and beyond the requirements of the law; what they say and do should not be taken as a reflection of the word of law. They may refuse to grant a certificate to a film, but that doesn't ipso facto demonstrate any illegality.
Further, the obscenity laws are sufficiently non-specific as to be useless; they don't need to change the law to permit certain things being shown, because the law never specifically forbade them in the first place.
Except that my old non-camera phone is a much better phone, and I wouldn't carry around a camera anyway. Nor would most people (as amply evidenced by the fact that prior to the release of camera phones they didn't).
As such, the camera phone falls squarely into the "solution looking for a problem" category.
And even if one really did want a camera, a camera phone would be hopelessly inadequate anyway; crap compared even to a disposable 35mm camera, let alone a proper one.
Because, since XML is not a format (but rather a standardized way of creating one's own formats) the issue of "creating a format" is not solved by the decision to use XML.
What XML "wins" is off-the-shelf parsers; one still needs to write some amount of code to convert dumb XML (elements and attributes and all that crud) into something with semantic meaning to your application.
For a simple application like this it's not clear that the overheads of XML (both in terms of size, computational complexity, and programmer overhead to make the aforementioned conversion) are at all worthwhile.
Allow me to summarize: Java has no pointers
Er, yes, it does.
Any object reference in Java is a pointer; it's why the exception is called a NullPointerException. Once one understands this, one can discard wrong-headed notions such as "Java has pass by reference", which are all too common, and all too wrong.
Java's pointers might not have pointer arithmetic (which seems to be why people claim them to be something other than pointers), but the key feature of a pointer is that it's an indirection, not that it can perform certain kinds of arithmetic. And Java's pointers are exactly that; they're pointers into the garbage-collected heap.
I mean, really. Pentiums?! This should be thrown out at the first opportunity. But then, the same was true of Eolas....
Hierarchical strongly typed securable storage is not a bad idea.
The registry may have been designed and implemented for storage of specific useful information which would contribute to interoperability between applications but it doesn't take a brain surgeon to look ahead and see that every screen saver, toolbar, and "neat app" author would start filling the registry full of excess junk keys that mean nothing to the rest of the system.So? It's not meant to. If it's under HKLM\VendorName\AppName\ then it's not *meant* to be meaningful to other applications. One would have thought that the fact that it's in a location private to the application would have made that obvious.
Additionally there are more than a few ways to hijackThis functionality is not anything provided by the registry (it may be stored there, but the functionality would remain the same if it were stored in a text file, no?); it's ignorant in the extreme to blame the registry for this kind of thing. It's not even clear that it's a bad thing; it seems to me that it's a feature that can be used for good or bad purposes. Much like other features, such as "running software". "The registry" has no functionality of its own; it's just a database.
That is why I blame MS for the registry. It would be a good idea if the user was consulted for every new key added. That can't be done because the user can't be bothered.That would render it useless.
Unfettered, unrestricted application access to a housekeeping system with as much clout as the registry should plain not be possible.It has no "clout", and access is neither unfettered nor unrestricted. Registry keys are securable objects. Since it's impossible to secure the registry the registry never should have been implemented.
It's as securable as anything else; registry keys have ACLs, so one can restrict the operations performed on them.
No doubt you'll bleat "oh, but since everyone in Windows uses Administrator that doesn't help". This is wrong on two counts; (1) not everyone uses Administrator (2) it doesn't help, but it doesn't help if they're a regular user either. Why doesn't it help? Because as a regular user (just as with regular users on Linux or OS X) they can destroy their own data; they can run malicious programs when they log in; they can send viral e-mails; they can run spyware. None of these things are privileged operations (and nor should they be). Permissions don't help in mostly single-user client computers. They can only protect pointless things such as the system's files. But you don't need them protected. You've already got them on the installation CD. They're not the things you've invested hundreds of hours in creating.
Er....
To claim that the Soviets could not (and hence did not) innovate is completely absurd. Organizations such as Electronorgtechnica (aka Elorg, to name one that everyone here ought to have heard of...) simply couldn't have existed without innovation to back them. Nor could the highly developed Soviet war machine or space programme.
They developed a lot of good hardware, and that required innovation on their part.
Centralized decision making does not mean "no innovation"; what it means is that the innovation is limited to those areas that the central decides will see development. And even then (as Elorg's most famous product shows), there was more freedom than you give them credit for.
gzip is the name of the compression format (RFC 1952) as well as the utility often used to create files using that format; as such a rewritten version is quite possible, and it wouldn't be surprising to find that the rewritten version is named something such as "gzip". And the zlib compression library itself (unlike the utility) isn't GPLed, in any case. It uses a sensible license instead. A cursory glance doesn't suggest that any of those files are from either project, however. elsewhere
I guess this is a figment of my imagination, right?
This dates back to 1999. Have there been any groundbreaking advances in the meantime?
How is this better than the Nescafe "Hot when you want" cans that have been for sale for some months? They're coffee in a can that heats itself before you drink it; they cost about a quid, a quid fifty. I don't know if they were limited-period trials or promotions, but they were certainly for sale towards the end of last year.
And several have said it isn't.
This is incorrect -- I invite you to actually try it out.
You can write unmanaged, unsafe code that targets the CLR. Take a look at this, if you don't believe it. A whole load of IL -- unmanaged, unsafe -- that targets the CLR.
The CLR supports a lot more than just the CTS. There is no reason for Eiffel# to restrict itself to the constraints of the CTS.
Perhaps you need to reread the article.
I'm aware of such languages, and I mentioned them. I'm also aware of the issues with them -- few of them can participate on an equal standing with Java (Jython appears to be the biggest exception to this), whereas the same is not generally true of the .NET languages. Only a small subset of those languages are call and inheritance compatible with Java, versus nearly all (if not all) of the .NET languages.
It's called ECMAScript, ECMA specification #262. Made by TC-39 as a vendor-neutral amalgamation of JScript and JavaScript. TC-39 is the group now working on C# and the CLI.
Er. That would be all well and good, if Java implementations weren't bug-free. There have been bugs in JVMs. Blessed, coffee-cupped, JVMs. There will, I'm quite sure, be bugs in future JVMs. Even from Sun. It's happened before, and no amount of "enforcement" makes people write perfect code.
Can you explain what aspect of the CLR makes a usermode thread implementation impossible (presumably this is how Erlang's "very efficient thread implementation" works)?
Hack your runtime to no longer care if an executable's stored hash doesn't match up with what it's calculated to be.