... the "free choice" argument does not work for monopoly players, especially the government itself.
Yes, we can't choose our own individual time zone or or own personal daylight saving time. They can only be done as a community. Similarly, units of measure have major implications for society as a whole and the government should standardise them.
Not yielding an inch, are they? Imagine the impact it would have on Subway.
I agree, asking for a 30.48 centimeter sandwich instead of a footlong just wouldn't work.
When Subway offer you a footlong, that is one foot to within, what, plus or minus half an inch? Converting to 30.48 centimetres implies a precision of.1 millimetres, which is ridiculous. Just a thirty would be fine, and about the same precision.
Cyclical relationships, which shouldn't exist in decent code
If a parent object refers to a child, and a child to a parent, that's a cycle.
For example, every GUI library I've ever seen has a container with a collection of widgets. The widget object has a reference back to its parent container.
The one-way, non-cyclical pointer has limitations too. One of the key insights of relational databases is that every relationship is bidirectional. If the relationship exists, often the time will come when you want to find the parent related object when what you have is the child one. With unidirectional pointers, you have to rewrite your application to achieve it.
Vim 7 will also have OmniComplete (it's in the dev tree already) which is pretty much like Intellisense if the using a period and getting a dropdown (instead of just getting a tab-completion style listing of matches) is really that a big deal to you.
Studio *6* had both these features. From what you say it's taken vim eight years to catch up.
I never said he could stop you, nor do I think he's infallible.
But it was an early design decision to have a large monolithic kernel, and AFAIK Linus still thinks it was a good one. We have a real, very usable OS. Other microkernel-based OSs seem to have taken a long time, be big on good design and small on functionality.
If you think a microkernel is so fundamental to a good OS, why not contribute to HURD or build on Mach instead of rewriting/refactoring Linux?
In 1996, Fred McLain realized there were security problems with ActiveX, and wrote an demonstration ActiveX control called Exploder. Exploder will shut down Windows - not do permanent damage, but of course the point was if he could do that he could do anything.
He then went to Verisign and got a certificate and signed the control, to prove the point that code signing doesn't guarantee the control is safe. There was a blaze of publicity at the time, and Verisign threatened to sue him if he didn't take the control off his web page. In the end he took down the signed control. The unsigned one is still there for your edification and enjoyment.
But synchronized has the same issue - there may be times that releasing the lock doesn't work and throws an exception. The JVM spec says the underlying monitorexit bytecode instruction can throw NullPointerException or IllegalMonitorStateException. Both of these are runtime exceptions that would most likely stop the whole application, and would certainly hide any exception that had occurred in the code within the block. As you might expect, the unlock() method of ReentrantLock can throw exactly the same exceptions.
I don't see why the exception is any more likely to occur if synchronized was implemented with ReentrantLock.
A developer choosing to directly use ReentrantLock in a stupid way might get exceptions, but that is the point of synchronized in the first place - simplify, automate and abstract to make it easier for the developer to write correct code.
The article on IBM's site gives two reasons to continue using synchronized, rather than replacing it with the new ReentrantLock class:
You must remember to release a ReentrantLock in a finally block, while synchronized does so automatically.
Older JVMs don't have the concurrency classes.
Given ReentrantLock has the same semantics as synchronized, performs better and has some extra features, why hasn't synchronized been redefined to use ReentrantLock? It would become compiler magic to, in effect, automatically generate a try-finally with a call to unlock() in the finally.
The dilemma about when to use ReentrantLock would go away. For simple situations and beginning programmers, just use synchronized, confident in the knowledge that where A Better Way is available, your code will get it, but it will still work fine on earlier JVMs (assuming synchronized ever worked on them).
The extra features of ReentrantLock are there when needed, and it's only when you use them that your code is Java 5 specific.
.NET, Java and many other garbage collectors use a "mark and sweep" technique (see Richard Jones's site for a discussion of GC algorithms). A closed loop of objects without other references into the circle is recognised as unreachable and therefore garbage collected.
An unneeded object will be GC'd even when part of an unneeded circle. If the object has a finalizer, it will be run.
Even if there is no need for a GC pass to reclaim memory, finalizers are run when an app is shut down.
Because if the typical Slashdot reader doesn't know the difference between an adjective (good) and an adverb (well), just how dumb must Microsoft employees be?
I share another posters scepticism - spraying as much silver iodide or ice as a plane can carry into the air created 250x normal rainfall out of nothing? Sure...
Australia has far more need of enhanced rainfall than Britain. There have been extensive trials by the Commonwealth Scientific and Industrial Research Organization (CSIRO) and overall cloud seeding does not work.
To quote from a
summary of CSIRO's findings: "CSIRO has shown that in Australia cloud seeding is effective only in a limited number of weather conditions. Cloud seeding will never break droughts; cloudless skies will never produce rain."
CSIRO have also produced guidelines for water managers considering trying cloud seeding. My take on their conclusion is: it won't work, save your money.
In contrast to all the the other databases you name, Access is not a database server, it's a file format. Any searching and processing of the data is done on the client side, not the server side.
So, the computer running your Web server would have to run the Access (aka Jet) software too. With the others you have the option of offloading the database to a different box and just transmitting the results over your network back to the web server.
Access also has an absolute upper limit of 255 simultaneous users. Just how many hits are you hoping for on this web site of yours?
Microsoft themselves are moving away from Jet for even lightweight standalone database work. Instead, they now have an "SQL Server Lite" - the Microsoft Database Engine (MSDE).
So, when the name of the record company changes from "CBS" to "Sony" we have to update thousands of records?
An ID can remain unchanged forever. Ted Codd, the inventor of the relational model, thought IDs are so important he made them built-in, i.e. mandatory, in his book The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). If he can't say what's relational, who can?
In what way are IDs non-relational in your point of view?
Slashdot Mirror
Charlie, read this.
http://geekfeminism.wikia.com/...
... the "free choice" argument does not work for monopoly players, especially the government itself.
Yes, we can't choose our own individual time zone or or own personal daylight saving time. They can only be done as a community. Similarly, units of measure have major implications for society as a whole and the government should standardise them.
Not yielding an inch, are they? Imagine the impact it would have on Subway.
I agree, asking for a 30.48 centimeter sandwich instead of a footlong just wouldn't work.
When Subway offer you a footlong, that is one foot to within, what, plus or minus half an inch? Converting to 30.48 centimetres implies a precision of .1 millimetres, which is ridiculous. Just a thirty would be fine, and about the same precision.
The International System of Units can go to hell.
Now, what country might you live in?
Two words for you: Debian backports.
Sigh.
This was news in August 2011.
http://www.theregister.co.uk/2011/08/31/afact_subcontractor_to_mpaa/
Steven Vaughan-Nichols is calling it "no longer as important as it once was". See http://www.zdnet.com/blog/open-source/the-new-debian-linux-irrelevant/8218
IANAL either, but ignorance is no excuse. You sign a contract, you abide by it, whether you read it thoroughly or not.
Cyclical relationships, which shouldn't exist in decent code
If a parent object refers to a child, and a child to a parent, that's a cycle.
For example, every GUI library I've ever seen has a container with a collection of widgets. The widget object has a reference back to its parent container.
The one-way, non-cyclical pointer has limitations too. One of the key insights of relational databases is that every relationship is bidirectional. If the relationship exists, often the time will come when you want to find the parent related object when what you have is the child one. With unidirectional pointers, you have to rewrite your application to achieve it.
Vim 7 will also have OmniComplete (it's in the dev tree already) which is pretty much like Intellisense if the using a period and getting a dropdown (instead of just getting a tab-completion style listing of matches) is really that a big deal to you.
Studio *6* had both these features. From what you say it's taken vim eight years to catch up.
This report says Customs will change from a single outsourcer, EDS, to several beginning in June 2007.
I never said he could stop you, nor do I think he's infallible.
But it was an early design decision to have a large monolithic kernel, and AFAIK Linus still thinks it was a good one. We have a real, very usable OS. Other microkernel-based OSs seem to have taken a long time, be big on good design and small on functionality.
If you think a microkernel is so fundamental to a good OS, why not contribute to HURD or build on Mach instead of rewriting/refactoring Linux?
Linus hates microkernels.
In 1996, Fred McLain realized there were security problems with ActiveX, and wrote an demonstration ActiveX control called Exploder. Exploder will shut down Windows - not do permanent damage, but of course the point was if he could do that he could do anything.
He then went to Verisign and got a certificate and signed the control, to prove the point that code signing doesn't guarantee the control is safe. There was a blaze of publicity at the time, and Verisign threatened to sue him if he didn't take the control off his web page. In the end he took down the signed control. The unsigned one is still there for your edification and enjoyment.
The whole sorry story can be found here.
But synchronized has the same issue - there may be times that releasing the lock doesn't work and throws an exception. The JVM spec says the underlying monitorexit bytecode instruction can throw NullPointerException or IllegalMonitorStateException. Both of these are runtime exceptions that would most likely stop the whole application, and would certainly hide any exception that had occurred in the code within the block. As you might expect, the unlock() method of ReentrantLock can throw exactly the same exceptions.
I don't see why the exception is any more likely to occur if synchronized was implemented with ReentrantLock.
A developer choosing to directly use ReentrantLock in a stupid way might get exceptions, but that is the point of synchronized in the first place - simplify, automate and abstract to make it easier for the developer to write correct code.
- You must remember to release a ReentrantLock in a finally block, while synchronized does so automatically.
- Older JVMs don't have the concurrency classes.
Given ReentrantLock has the same semantics as synchronized, performs better and has some extra features, why hasn't synchronized been redefined to use ReentrantLock? It would become compiler magic to, in effect, automatically generate a try-finally with a call to unlock() in the finally.The dilemma about when to use ReentrantLock would go away. For simple situations and beginning programmers, just use synchronized, confident in the knowledge that where A Better Way is available, your code will get it, but it will still work fine on earlier JVMs (assuming synchronized ever worked on them).
The extra features of ReentrantLock are there when needed, and it's only when you use them that your code is Java 5 specific.
Why wasn't it done this way?
See this Slashdot discussion from December on similar topics.
Microsoft designed in the IDisposable interface, give examples of how to use it, and use it in their own library.
Seems like a fair attempt to teach people and figure out how to use GC wisely to me.
An unneeded object will be GC'd even when part of an unneeded circle. If the object has a finalizer, it will be run.
Even if there is no need for a GC pass to reclaim memory, finalizers are run when an app is shut down.
Because if the typical Slashdot reader doesn't know the difference between an adjective (good) and an adverb (well), just how dumb must Microsoft employees be?
I share another posters scepticism - spraying as much silver iodide or ice as a plane can carry into the air created 250x normal rainfall out of nothing? Sure...
Australia has far more need of enhanced rainfall than Britain. There have been extensive trials by the Commonwealth Scientific and Industrial Research Organization (CSIRO) and overall cloud seeding does not work.
To quote from a summary of CSIRO's findings: "CSIRO has shown that in Australia cloud seeding is effective only in a limited number of weather conditions. Cloud seeding will never break droughts; cloudless skies will never produce rain."
CSIRO have also produced guidelines for water managers considering trying cloud seeding. My take on their conclusion is: it won't work, save your money.
For Baran's point of view, see this interview at Wired.
At the time I write this (11:12 am Australian Eastern Standard), Microsoft's announcement of this vulnerability at was dated May 18, not June 18.
Sheesh.
In contrast to all the the other databases you name, Access is not a database server, it's a file format. Any searching and processing of the data is done on the client side, not the server side.
So, the computer running your Web server would have to run the Access (aka Jet) software too. With the others you have the option of offloading the database to a different box and just transmitting the results over your network back to the web server.
Access also has an absolute upper limit of 255 simultaneous users. Just how many hits are you hoping for on this web site of yours?
Microsoft themselves are moving away from Jet for even lightweight standalone database work. Instead, they now have an "SQL Server Lite" - the Microsoft Database Engine (MSDE).
So, when the name of the record company changes from "CBS" to "Sony" we have to update thousands of records?
An ID can remain unchanged forever. Ted Codd, the inventor of the relational model, thought IDs are so important he made them built-in, i.e. mandatory, in his book The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). If he can't say what's relational, who can?
In what way are IDs non-relational in your point of view?