He (and probably most people, unfortunately) doesn't know about a nice common browser feature. If you click on the drop down menu for a select box and start typing the option you want, it will actually select it. So there isn't really an advantage in a text box over a select box, since a select box acts like a text box except with tab complete and a list of options.
Of course, it is a common flaw in web browsers that they don't make this functionality obvious.
They didn't skip any versions. They dropped the "1", which never meant anything. They went from "Java" to "Java 2" without changing the "1", which doesn't make any sense. They just resolved the Java 1.2/2.0 mess the wrong way back then, and they've correctly it by ditching the useless part. They should probably now make J2SE, J2EE, and J2ME not stand for anything, and the version scheme will make perfect sense.
Except that you still have to make sure you select the whole delete command to execute. The original poster had typed the right delete, but messed up highlighting it with the mouse.
If you were restricted to a single user interface style, you wouldn't be able to find a good option for people who can't right click. Actually, a CLI is much better than a GUI for people who don't use the mouse reliably.
I suspect that the Linux-Java link is largely that Java lets you run on any platform, and Linux is the best platform when you have no requirements for the platform. If you are planning to run purely Java software, you can choose your platform based on cost, performance, stability, etc., rather than worrying about features and migration cost.
I think that it is not particularly the case that Java is popular in the Linux world, but that Linux is popular (as least as a deployment platform) in the Java world, and that is a substantial portion of the Linux world as seen in business.
One thing you have to realize is that most of the world we experience isn't objectively real. The colors you perceive around you are highly affected by your perception of lighting conditions, for example, and so what is sometimes experienced as a red object under white light is at other times experienced as a white object under red light, despite exactly the same emitted light. There are also two spots where your retinas have no sensitivity, but your brain fills in the information.
So your everyday experience is a big hallucination which correlates well with some properties of interest in the real world. Hallucinogens will change your perceptions such that your experience correlates well with different properties of the real world, which you will find strange. In fact, you are likely to experience something closer to your actual perception than to the conventional processed version your brain normally produces. You might see a bowl of water as being full of flashes of light, when it does actually produce flashes of light by reflecting with little waves; under normal conditions, you would experience it as a bowl of water shaking slightly under a light.
So the difference between what we call normal perception and hallucination is not whether our brains make up what we see, but whether what they make up is a useful description of the real world. Internal features like "modes of consciousness" aren't part of the real world anyway, so it is hard to say what the difference between a real mode of conscious and a hallucinated one would be.
It does seem like a legitimate risk that, if you've ever done business with SCO, or maybe even if not, and you're using Linux, SCO might come after you. Saying that Linux is legally sound is like saying that you don't owe any muggers any money. It's true, but that doesn't really matter. By the time you actually get to prove your case, you'll have had to spend a significant amount of time in court, and SCO will probably go bankrupt and be unable to pay your legal bills by the time you win.
Actually, the issue isn't including HTML rendering engines, but rather invoking them. Why exactly a web browser would invoke an external HTML rendering engine is beyond me, though.
Your application is actually ideal for self-signed certs. What you should do is print the certificate fingerprint on business cards and physically hand them to your friends. That way, when the browser pops up the box asking them if they want to verify the certificate, they can actually verify it against information they personally trust directly. This is a much stronger level of trust than anything involving Verisign, because someone would have to successfully impersonate you to your friends, rather than simply convincing some CA somewhere.
Of course, they're vulnerable to spoofing when they accept the certificate if they aren't checking the fingerprint. They should at least accept the certificate permanently, so that they would get a message they aren't used to if it ever changes.
Well, one step in convincing bob porn producer is having a demo available. If the format is available in common players or has a plug-in, and the quality is good, and the software is cheap, it's a good format. This demo would be useful for evaluating the option.
I think that the reason our system was good was that it was a pretty thin layer over SQL. It kept the same model as SQL has, but did little things like having a set of constants for your database tables so that their names (and schemas) could be changed easily. It let you add an additional copy of a table with an unused alias without keeping track yourself of what aliases were used. It let you write a subquery like a query, and use the subquery like a table (without knowing that it wasn't actually a table).
There was a bunch of trickiness, but that was in a separate layer on top of the query generation layer. I believe we ended up with code that just used the query (and other command) generation directly, code that used a "search with restrictions" layer, and code that used a "build an n-dimensional table of values" layer. I think part of why it worked and didn't drive anyone particularly insane (beyond the fact that arrays of varying dimensionality in Java are a bit insane, and, in the JDK we were using, buggy) was that the layers were kept strictly separate with all of the cleverness out of the way of code that needed different cleverness.
I'm actually in the process of trying to write something similar for my own use (and GPL, if I ever overcome my shyness about releasing things). My current problem is that I don't have any problems which use a sufficiently complex database to really hone the tools. Oh, and the low copiousness of my spare time, of course.
Those are persistance layers for Java, giving you OODB functionality. They're basically useless, however, if you have problems which are relational in nature. If you're doing a lot of complex searches, you really want to have the database implement the query. If you have an OLAP-style fact table, the OODB design doesn't make any sense.
Torque et al do work well for persistance of objects, which is something that a lot of people want. But that's not the problem we're discussing here; we're discussing OO code for handling relational data, not code for handling object data in a realtional database.
Probably not in general, but if you have a large complex, it might be. MIT, for example, has a cogeneration power plant, which produces chilled water, steam, and electricity. The demand for various products affects the rate that the generator has to run, which affects the amount of the others produced. So MIT electricity prices change every 10 seconds (there's a web page which updates at that rate), based on how much other stuff is being used. Furthermore, MIT is on the city grid, and buys any power over what the generator produces at a higher cost. If more than 20 MW are being used, then the amount used affects the percentage that's locally produced, and therefore the average cost.
So, if it's winter and the heat is on (requiring the generator to run full power), and campus is using less than the 20 MW produced, it makes sense to run the freezers longer such that they'll require less power later when the campus is using more power.
It seems to me like NAC can comply with that by simply not assigning the addresses to anybody else. Messing up the upstream provider's routing tables such that it actually works isn't something NAC can do.
If you were to sue the owner of an apartment building you were moving out of to retain your address, the owner would keep putting your mail in your mailbox. The owner of the apartment building is not preventing you from receiving mail addressed to your old address wherever you are; it's the postal service that does that.
So it seems like the customer can't really make use of this judgement, since it would require finding a carrier who could, even with NAC's permission, deliver the packets. The exception is that they could keep using NAC as an ISP, which is the only thing they'd be able to get to work, and which is really the sensible thing for such an injunction to do.
It took Linus about a year (1994-1995) to do the Alpha port, which was 64-bit, a completely different architecture from x86, and required adding support for having multiple architectures in the same tree. Of course, making something 64-bit clean is easier if there's less of it, and Linux was small then.
At the lowest layer, it was essentially a system which let you put together a SQL command incrementally. If you want to do an insert, you create an InsertCommand for the table, and then call setColumn() methods for the columns with the desired values. If you want to do an update, it is similar, but you can also add restriction clauses, either by simply requiring an exact match or with a method taking Operand, Relation, Operand. There was support for, essentially, "insert or update row" (like "create or replace view"), which would do the correct operation for the current state of the database without having you write each case and test them yourself. The support for "select" was somewhere in the middle of the range of functionality supported by different SQL extensions.
So it actually followed almost exactly the functionality provided by SQL, but it allowed you to put it together incrementally rather than with a string constant, so you could have a method on a different object which would take a query so far and a user and apply to the query the access restrictions for that user. Applicability to different problems should, therefore, by approximately the same as an average SQL implementation. It also had the advantage of being able to generate SQL suitable for different databases, so it had a wider applicabilty than completely portable SQL would.
Of course, the reporting engine was solving a specific problem in a clever way, using the framework. It is true that I extended the framework in a few ways (to include GROUP BY and nested queries) which writing the reporting engine, so you could argue that, until I used it to solve the third (or so) dissimilar problem, it wasn't yet sufficiently general. Still, it would regularly build up substantially more complex queries than either I or our DBA could have written in SQL.
A particular point I want to make about it is that it wasn't an OO databse system; it was an OO interface to queries in a relational database system. A lot of OO database systems in OO languages have been written, and these are generally less applicable to a large class of problems than relational databases. What most people write are persistance layers for objects, which are much less useful in a lot of situations.
Actually, SQL is the interface to every non-toy scale data storage project. Non-toy databases are not SQL inside, but use SQL as the high-level language that they compile into their execution plans. SQL is the sole interface language supported by databases with efficient internal implementations, and therefore all of SQL's flaws are overwhelmed in the marketplace by the fact that it's what the good software uses. It's like the named.conf format, which is widely used, but only because it's what BIND uses, not because it's actually good.
If Oracle started supporting a more friendly API, people would use it instead. I've actually written (for a former company) an OO system for putting together relational queries. With this, I wrote a reporting engine such that you could define a report in an XML file, and it would build the right query and organize the data. It ran better than hand-written SQL queries, and was much easier to write. Of course, it used a SQL back-end to interface with Oracle, but it would have been more efficient if it didn't have to build up a huge query string and then have Oracle parse it. It also would have been nice if I weren't constrained by SQL's limitations. Why can't I have a temporary table with completely specified contents nested in a SELECT statement? It would greatly improve my implementation of "average(x), index(range) for y in range in list(ranges)" (This is just a gloss; the actual code was a bunch of Java applied at various points to a query object.)
In most Western music, those would probably be the next notes, but other idioms actually have scales built on different principles.
I suspect that atonal music is to most people a bit like people talking in Italy would be to an ASL speaker. There are hand gestures going on, and they are related to the conversation, but they don't have a complete meaning like they're expected to. I suspect that there are other properties to atonal music which are the organizing properties (whether or not even an experienced listener can hear them) and which do follow a Zipf law.
If an extortion victem is willing to go to the cops, it's already not going to work very well. If catching you is worth the information getting out, then you don't have sufficiently valuable information.
It's not a 20 year monopoly on the arrangement of stuff. It's a 20-year monopoly on an arrangement of stuff. People are perfectly free to arrange their stuff in some other way. And kiosks for getting money in a bank does seem novel to me.
If you come up with a new way of making broken furniture useable, or if you find a place to put the towels that nobody has ever put them before, you're welcome to get a 20-year monopoly.
There is a difference between writing portable code and writing code for a cross-platform system. You will do better if you pick from the beginning the system you are writing for, and write only for that system. You will also do better if you have a set of tools which insists that you make no assumptions beyond those that the system provides.
The sort of non-portability which is bad is when you depend on things which are not always true of your system. This is what leads people to design sites that look ugly with browser sizes other than the one they test with. If you're trying to make a web page, as opposed to an IE page, you need to test against web standards.
The sort of portability which is bad is where you are developing for multiple systems which are different in ways that matter. This is what leads to web sites that work with only IE and Netscape 4.7.
If you need to support multiple platforms, it often makes sense to write two independant versions, rather than try to have a single cross-platform version. Or you can have two versions of the platform-dependant portion, and a common portion whose system is your library. But trying to have a single device driver for both Windows and Linux is just going to be hopeless as well as pointless.
The thesis tested one of those at the trade show. You wear the artificial fingertip on your real hand, so it contains normal human tissue and bone structure. In fact, the real issue is that a real finger has a bunch of non-distinctive live matter covered by a layer of distinctive dead matter (your epidermis, with your fingerprints, is dead cells). It's very difficult to detect the difference between dead matter that's supposed to be there and dead matter that's not supposed to be there.
Obviously, wearing the fake on your real hand is necessary if you want to fool the security guard as well.
That worked until other computer giants started pushing Linux. When Microsoft says something's not serious, but IBM spends a billion dollars marketing it, Oracle says it's their preferred platform, and Dell sells it on their big machines, it's pretty clear that Microsoft is failing to understand customer requirements. "Everybody else is talking about Linux, but Microsoft doesn't seem to know anything about it" leads to "Microsoft is not keeping up to date on technology". Of course, if everybody else weren't talking about Linux, Microsoft would have just kept saying nothing about it.
What I want is a fuel cell system that runs on those little bottles. Sure, they're not as cheap as methanol, but they come conveniently packaged in manageable sizes and can be bought on airplanes.
Slashdot Mirror
He (and probably most people, unfortunately) doesn't know about a nice common browser feature. If you click on the drop down menu for a select box and start typing the option you want, it will actually select it. So there isn't really an advantage in a text box over a select box, since a select box acts like a text box except with tab complete and a list of options.
Of course, it is a common flaw in web browsers that they don't make this functionality obvious.
They didn't skip any versions. They dropped the "1", which never meant anything. They went from "Java" to "Java 2" without changing the "1", which doesn't make any sense. They just resolved the Java 1.2/2.0 mess the wrong way back then, and they've correctly it by ditching the useless part. They should probably now make J2SE, J2EE, and J2ME not stand for anything, and the version scheme will make perfect sense.
Except that you still have to make sure you select the whole delete command to execute. The original poster had typed the right delete, but messed up highlighting it with the mouse.
If you were restricted to a single user interface style, you wouldn't be able to find a good option for people who can't right click. Actually, a CLI is much better than a GUI for people who don't use the mouse reliably.
I suspect that the Linux-Java link is largely that Java lets you run on any platform, and Linux is the best platform when you have no requirements for the platform. If you are planning to run purely Java software, you can choose your platform based on cost, performance, stability, etc., rather than worrying about features and migration cost.
I think that it is not particularly the case that Java is popular in the Linux world, but that Linux is popular (as least as a deployment platform) in the Java world, and that is a substantial portion of the Linux world as seen in business.
One thing you have to realize is that most of the world we experience isn't objectively real. The colors you perceive around you are highly affected by your perception of lighting conditions, for example, and so what is sometimes experienced as a red object under white light is at other times experienced as a white object under red light, despite exactly the same emitted light. There are also two spots where your retinas have no sensitivity, but your brain fills in the information.
So your everyday experience is a big hallucination which correlates well with some properties of interest in the real world. Hallucinogens will change your perceptions such that your experience correlates well with different properties of the real world, which you will find strange. In fact, you are likely to experience something closer to your actual perception than to the conventional processed version your brain normally produces. You might see a bowl of water as being full of flashes of light, when it does actually produce flashes of light by reflecting with little waves; under normal conditions, you would experience it as a bowl of water shaking slightly under a light.
So the difference between what we call normal perception and hallucination is not whether our brains make up what we see, but whether what they make up is a useful description of the real world. Internal features like "modes of consciousness" aren't part of the real world anyway, so it is hard to say what the difference between a real mode of conscious and a hallucinated one would be.
It does seem like a legitimate risk that, if you've ever done business with SCO, or maybe even if not, and you're using Linux, SCO might come after you. Saying that Linux is legally sound is like saying that you don't owe any muggers any money. It's true, but that doesn't really matter. By the time you actually get to prove your case, you'll have had to spend a significant amount of time in court, and SCO will probably go bankrupt and be unable to pay your legal bills by the time you win.
Actually, the issue isn't including HTML rendering engines, but rather invoking them. Why exactly a web browser would invoke an external HTML rendering engine is beyond me, though.
Your application is actually ideal for self-signed certs. What you should do is print the certificate fingerprint on business cards and physically hand them to your friends. That way, when the browser pops up the box asking them if they want to verify the certificate, they can actually verify it against information they personally trust directly. This is a much stronger level of trust than anything involving Verisign, because someone would have to successfully impersonate you to your friends, rather than simply convincing some CA somewhere.
Of course, they're vulnerable to spoofing when they accept the certificate if they aren't checking the fingerprint. They should at least accept the certificate permanently, so that they would get a message they aren't used to if it ever changes.
Well, one step in convincing bob porn producer is having a demo available. If the format is available in common players or has a plug-in, and the quality is good, and the software is cheap, it's a good format. This demo would be useful for evaluating the option.
I think that the reason our system was good was that it was a pretty thin layer over SQL. It kept the same model as SQL has, but did little things like having a set of constants for your database tables so that their names (and schemas) could be changed easily. It let you add an additional copy of a table with an unused alias without keeping track yourself of what aliases were used. It let you write a subquery like a query, and use the subquery like a table (without knowing that it wasn't actually a table).
There was a bunch of trickiness, but that was in a separate layer on top of the query generation layer. I believe we ended up with code that just used the query (and other command) generation directly, code that used a "search with restrictions" layer, and code that used a "build an n-dimensional table of values" layer. I think part of why it worked and didn't drive anyone particularly insane (beyond the fact that arrays of varying dimensionality in Java are a bit insane, and, in the JDK we were using, buggy) was that the layers were kept strictly separate with all of the cleverness out of the way of code that needed different cleverness.
I'm actually in the process of trying to write something similar for my own use (and GPL, if I ever overcome my shyness about releasing things). My current problem is that I don't have any problems which use a sufficiently complex database to really hone the tools. Oh, and the low copiousness of my spare time, of course.
Those are persistance layers for Java, giving you OODB functionality. They're basically useless, however, if you have problems which are relational in nature. If you're doing a lot of complex searches, you really want to have the database implement the query. If you have an OLAP-style fact table, the OODB design doesn't make any sense.
Torque et al do work well for persistance of objects, which is something that a lot of people want. But that's not the problem we're discussing here; we're discussing OO code for handling relational data, not code for handling object data in a realtional database.
Probably not in general, but if you have a large complex, it might be. MIT, for example, has a cogeneration power plant, which produces chilled water, steam, and electricity. The demand for various products affects the rate that the generator has to run, which affects the amount of the others produced. So MIT electricity prices change every 10 seconds (there's a web page which updates at that rate), based on how much other stuff is being used. Furthermore, MIT is on the city grid, and buys any power over what the generator produces at a higher cost. If more than 20 MW are being used, then the amount used affects the percentage that's locally produced, and therefore the average cost.
So, if it's winter and the heat is on (requiring the generator to run full power), and campus is using less than the 20 MW produced, it makes sense to run the freezers longer such that they'll require less power later when the campus is using more power.
It seems to me like NAC can comply with that by simply not assigning the addresses to anybody else. Messing up the upstream provider's routing tables such that it actually works isn't something NAC can do.
If you were to sue the owner of an apartment building you were moving out of to retain your address, the owner would keep putting your mail in your mailbox. The owner of the apartment building is not preventing you from receiving mail addressed to your old address wherever you are; it's the postal service that does that.
So it seems like the customer can't really make use of this judgement, since it would require finding a carrier who could, even with NAC's permission, deliver the packets. The exception is that they could keep using NAC as an ISP, which is the only thing they'd be able to get to work, and which is really the sensible thing for such an injunction to do.
It took Linus about a year (1994-1995) to do the Alpha port, which was 64-bit, a completely different architecture from x86, and required adding support for having multiple architectures in the same tree. Of course, making something 64-bit clean is easier if there's less of it, and Linux was small then.
At the lowest layer, it was essentially a system which let you put together a SQL command incrementally. If you want to do an insert, you create an InsertCommand for the table, and then call setColumn() methods for the columns with the desired values. If you want to do an update, it is similar, but you can also add restriction clauses, either by simply requiring an exact match or with a method taking Operand, Relation, Operand. There was support for, essentially, "insert or update row" (like "create or replace view"), which would do the correct operation for the current state of the database without having you write each case and test them yourself. The support for "select" was somewhere in the middle of the range of functionality supported by different SQL extensions.
So it actually followed almost exactly the functionality provided by SQL, but it allowed you to put it together incrementally rather than with a string constant, so you could have a method on a different object which would take a query so far and a user and apply to the query the access restrictions for that user. Applicability to different problems should, therefore, by approximately the same as an average SQL implementation. It also had the advantage of being able to generate SQL suitable for different databases, so it had a wider applicabilty than completely portable SQL would.
Of course, the reporting engine was solving a specific problem in a clever way, using the framework. It is true that I extended the framework in a few ways (to include GROUP BY and nested queries) which writing the reporting engine, so you could argue that, until I used it to solve the third (or so) dissimilar problem, it wasn't yet sufficiently general. Still, it would regularly build up substantially more complex queries than either I or our DBA could have written in SQL.
A particular point I want to make about it is that it wasn't an OO databse system; it was an OO interface to queries in a relational database system. A lot of OO database systems in OO languages have been written, and these are generally less applicable to a large class of problems than relational databases. What most people write are persistance layers for objects, which are much less useful in a lot of situations.
Actually, SQL is the interface to every non-toy scale data storage project. Non-toy databases are not SQL inside, but use SQL as the high-level language that they compile into their execution plans. SQL is the sole interface language supported by databases with efficient internal implementations, and therefore all of SQL's flaws are overwhelmed in the marketplace by the fact that it's what the good software uses. It's like the named.conf format, which is widely used, but only because it's what BIND uses, not because it's actually good.
If Oracle started supporting a more friendly API, people would use it instead. I've actually written (for a former company) an OO system for putting together relational queries. With this, I wrote a reporting engine such that you could define a report in an XML file, and it would build the right query and organize the data. It ran better than hand-written SQL queries, and was much easier to write. Of course, it used a SQL back-end to interface with Oracle, but it would have been more efficient if it didn't have to build up a huge query string and then have Oracle parse it. It also would have been nice if I weren't constrained by SQL's limitations. Why can't I have a temporary table with completely specified contents nested in a SELECT statement? It would greatly improve my implementation of "average(x), index(range) for y in range in list(ranges)" (This is just a gloss; the actual code was a bunch of Java applied at various points to a query object.)
In most Western music, those would probably be the next notes, but other idioms actually have scales built on different principles.
I suspect that atonal music is to most people a bit like people talking in Italy would be to an ASL speaker. There are hand gestures going on, and they are related to the conversation, but they don't have a complete meaning like they're expected to. I suspect that there are other properties to atonal music which are the organizing properties (whether or not even an experienced listener can hear them) and which do follow a Zipf law.
If an extortion victem is willing to go to the cops, it's already not going to work very well. If catching you is worth the information getting out, then you don't have sufficiently valuable information.
It's not a 20 year monopoly on the arrangement of stuff. It's a 20-year monopoly on an arrangement of stuff. People are perfectly free to arrange their stuff in some other way. And kiosks for getting money in a bank does seem novel to me.
If you come up with a new way of making broken furniture useable, or if you find a place to put the towels that nobody has ever put them before, you're welcome to get a 20-year monopoly.
Running on ethanol is the first step, but I want the device that you plug a 50ml plastic bottle of vodka into.
There is a difference between writing portable code and writing code for a cross-platform system. You will do better if you pick from the beginning the system you are writing for, and write only for that system. You will also do better if you have a set of tools which insists that you make no assumptions beyond those that the system provides.
The sort of non-portability which is bad is when you depend on things which are not always true of your system. This is what leads people to design sites that look ugly with browser sizes other than the one they test with. If you're trying to make a web page, as opposed to an IE page, you need to test against web standards.
The sort of portability which is bad is where you are developing for multiple systems which are different in ways that matter. This is what leads to web sites that work with only IE and Netscape 4.7.
If you need to support multiple platforms, it often makes sense to write two independant versions, rather than try to have a single cross-platform version. Or you can have two versions of the platform-dependant portion, and a common portion whose system is your library. But trying to have a single device driver for both Windows and Linux is just going to be hopeless as well as pointless.
The thesis tested one of those at the trade show. You wear the artificial fingertip on your real hand, so it contains normal human tissue and bone structure. In fact, the real issue is that a real finger has a bunch of non-distinctive live matter covered by a layer of distinctive dead matter (your epidermis, with your fingerprints, is dead cells). It's very difficult to detect the difference between dead matter that's supposed to be there and dead matter that's not supposed to be there.
Obviously, wearing the fake on your real hand is necessary if you want to fool the security guard as well.
That worked until other computer giants started pushing Linux. When Microsoft says something's not serious, but IBM spends a billion dollars marketing it, Oracle says it's their preferred platform, and Dell sells it on their big machines, it's pretty clear that Microsoft is failing to understand customer requirements. "Everybody else is talking about Linux, but Microsoft doesn't seem to know anything about it" leads to "Microsoft is not keeping up to date on technology". Of course, if everybody else weren't talking about Linux, Microsoft would have just kept saying nothing about it.
What I want is a fuel cell system that runs on those little bottles. Sure, they're not as cheap as methanol, but they come conveniently packaged in manageable sizes and can be bought on airplanes.