Pretty? Please, his site is ugly. I'm a webdesigner and i can tell you that if i'd deliver such a product to pretty much any customer, they'd slap me back to my office.
Right. So much better for you make something pretty and distinctive and quite often irritating to your customer's customers. So much better to have fancy gizmos that show off your customer's broadband and annoy your customer's customers on flaky dialup. You much better to use scripts and effects to wow your customer while making the site unusable for your customer's customers who have the sense to kill those malware attractors.
It may be plain and simple, but if I have to mess with a lot of it, I think I'd find stuff done like his site much less irritating and wearing.
Ok, I'm an old fart and IMNSHO more cynical than you. "We will just make the windows version and force the linux people to use Cedega if they want to use our stuff"... and watch all our customers slowly jump ship to our competitors who do it native. That's a short-term bridge. Only. There is a difference between the "real thing" and "not exactly". It's slow. It's subtle. But it does matter.
I'm sorry but I fail to see how your idea of a cloud is better than a well organized file tree?
The well organized file tree is best assuming that you use the exact same tree to store the file as to access the file. Problems are that well organized doesn't come cheap and that the optimum tree structure changes over time. Add to that the fact that you really want the ability to recover information from files based on entirely different criteria than those used to initially store the file. The cloud is not a mechanism for finding stuff, it is the initial starting point from which he wants to be able to find stuff.
Longhorn will make more extensive use of them, I'm certain
Ditto the viruses.
Re:Scalability and Maintainability go hand in hand
on
On PHP and Scaling
·
· Score: 1
numbers in identifiers -- the obvious I1 I2 J1 J2 A3PJ7Q
$ @ % to distinguish data types -- particularly if they occupy different name-spaces. Much cleaner if $foo @foo %foo co-exist and are handled differently.
contrived data naming scheme -- Mathematics and Engineering tend to love single-character names. They've been in the business for a long time. I suspect they know something about keeping your head straight when facing complexity. It helps immensely when something that is different looks different.
If the project is small enough, anything that distinguishes "this" from "that" will do nicely. When the project is large, something systematic must be done so that someone who has never seen the code or the variables before knows exactly what they represent. I suspect that something like hungarian notation manages to be exact on what doesn't matter at the expense of sloppiness on what does matter;-)
You can't operate a business without money, so if people can just come along and steal your ideas, you're screwed. Some people innovate for genuine interest because they are already independently wealthy and can afford to not make money, the same is not true for corporations, who have shareholders to report to.
Question. Is Seagate making all they money from spam that they could? If not, why not?
You can't operate a business without money. True. So if people can just come along and steal your ideas, you're screwed. Doesn't follow. If they can take the ideas and deprive you of your use of them, then probably so. If your business depends on you being the only one with ideas then it holds. In the world of high fashion, where the ideas matter very much, people can and do "just come along and steal your ideas." I don't think the high-fashion designers are going broke.
Corporations are responsible to their shareholders. And to their employees and to their customers and to their suppliers and to the comumities in which they operate.
Re:Scalability and Maintainability go hand in hand
on
On PHP and Scaling
·
· Score: 1
What unique attributes of perl do you believe contribute to your claim that perl "can become unmaintainable on a small project"?
Hardly unique, but it uses letters and numbers and some special characters for identifiers and other stuff. The way these are/can be used allows perl (or any other language) to become unmaintainable on a small project. With adequate care of assinging identifiers it would be possible to maintain very large projects using old FORTRAN 6-character name space. I'm sure it would also be possible to build large, complicated, dynamic systems in COBOL.
Sound inefficient, sure, but it works like a champ
Efficiency is always a matter of never being too inneficient for the context. Basically, you have a certain amount of time in which to do whatever it is you need to do. Faster isn't really any better, but slower always hurts.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 1
Instead of doing that, why not learn how to use the dbms the way it was intended to be used, natively? Learn SQL well, not as a metaphor for objects. Learn how to optimize queries; don't just throw in some caching layer on top of your slow SQL queries and pretend you've solved anything. Instead, all you done is trade data freshness for speed, badly, and introduced state into your app server.
All that matters is that it will work with higher demand. Who cares how or why.
Completely correct until you have to figure out whether or not it is scalable, for your required definition of scalable.
"subjectable" [can be made subject to...] methinks is the correct word, whether or not anyone else has previously used it. "subjective" would also work but gives a much weaker meaning to the sentence. You can make the term "scalable" mean what you want/need it to mean. I can ditto independently.
I think in general it means that within the expected range of increased load, the costs, etc are essentially linear. Traffic jams are a ubiquitous example of non-scaleable traffic systems. You reach a point where changes in results are all out of proportion to changes in inputs.
I remember the difference between that early Excel and Lotus, too. Lotus had more checklist features for a long time, but Excel -- it was just plain beautiful and fun to use.
WYSIWYG attempts by Lotus never did really work very well. Most spreadsheets are just a tabular presentation of some data with maybe a wee bit of calculation, and most of that calculation is simulating a 10-key adding machine.
You're very right. Marketing and Sales are very different creatures and quite often have nothing to do with each other.
If you accidentally import the bank data twice, both packages will happily post it twice, and you'll spend an hour removing the double posts. That's not support. [Emphasis added]
From what I have seen, that is support. That seems to match anyone's definition of whether they support something or not. I have even seen a case where something was supported by turning off that something.
I think that "supported" really only means that it is acceptable help-desk fodder. Totally unrelated to whether or not it works or how well.
Now what supported should mean, I gotta agree with you. But if you go by what it should mean, OpenBSD is user-friendly and Microsoft Windows is not user-friendly.
we had rackmount Pc's that would have almost 1/4 inch of metal/sand dust on the motherboards and the computers were STILL working.
Contacts that are exposed to a "harsh" environment generally form a very thin non-conductive film due to oxidation and/or corosion. This would also apply to any conductive surfaces. Depending on exactly what gets laid down, what you describe seems completely reasonable. However, something in a "clean" environment can easily be killed by something your self-protected PCs wouldn't even notice.
I suppose in the mean time we'll have to do our own safeguarding if we are in a risky area.
Hmmmm, seems like if you wanted to grow something like zink whiskers, you'd want a nice stable environment, free of foreign contaminants, and time, lots of time. From this standpoint, a dusty garage is a safer environment than a carefully controlled data center. Problems with monocultures.
What drug was the IE design team engineers taking when they decided to to let (or at least failed to prevent) untrusted program execution?
Assuming several layers in the hierarchy, the goons in the trenches are designing and coding to make themselves look better to their superiors who in turn are trying to impress their superiors. The old game of "gossip" applies, and even if common sense exists somewhere in the hierarchy, it will be blunted in favor of something, anything that will impress the higher-ups. Superficial glitz will triumph over basic competence regardless of anyones' attempts otherwise.
The amount of eye-candy is not really a valid metric. If you're good, damned good, you can "get away with anything". The wannabes will be confused into thinking you're good because of the eye-candy whereas the reality is quite different. (Microsoft caters to the wanabe crowd. Just look at their ads;) Run a good screen saver on a Linux Server, it's a cheap and effective way to monitor server health.
Except that he does have a very good idea of which window is which. It's subliminal, but they are laid down, left to right, in the same order that he opened them. With taskbar grouping, they're all there, but with no indication of which one is which.
kind of like cross-examining a Microsoft executive in court
or using Microsoft software. If it doesn't work the first time, try again, second or third try often works. Exactly the opposite behavior one expects from OpenBSD.
How is BPL a bad idea? Aside from the problems that need to be worked out with interference with hobbists, this could be a legitimate alternative to dsl and cable.
Imagine running gigabit ethernet over silver-satin telephone wire. Now imagine applying several thousand volts to the same wires.
The problems are not just with the hobbiests, they're just the first to notice because they happen to be interested in such things.
Assuming that crocodiles and dragon lizards (and probably vultures) have similar bad breath, T-Rex would almost certainly be also quite similar. The major ingredients would have to be chemicals given off by decomposing animal tissue. What T-Rex ate would matter more than anything else. The human nose is quite sensitive to (unacustomed) decomposition byproducts, enough so that Japanese find most westerners to have a very offensive body odor (from rotting hamburgers).
I think the semantics for NULL is that the row for that column value does not exist. NULL is not a value, it is a mechanism to indicate the lack of a place that would hold that value.
What you don't know has a way of messing up any and all grandiose plans.
He was right about one thing. Anything that is capable of being represented will most likely be represented. A good choice of representation can deprive an awful lot of nasty problems of any means of expressing themselves. Getting rid of "almost all" still leaves plenty;-(
They simply believe that "nulls" are a hack around the real need of supporting full value domains.
Thanks, makes sense. However, the required complexity required to handle "the real need of supporting full value domains" has to be sufficient to handle all possible reasons and scenarios where you do not have a simple value. You might get close with a Lisp back-end, but this is heading too much like needing a supercomputer to hand one number in an el-cheapo caculator.
Nulls are a hack. A nice simple hack. It is possible to build bigger and more complicated hacks and take things a wee bit further, but the further the screwier I'd expect.
Slashdot Mirror
Pretty? Please, his site is ugly. I'm a webdesigner and i can tell you that if i'd deliver such a product to pretty much any customer, they'd slap me back to my office.
Right. So much better for you make something pretty and distinctive and quite often irritating to your customer's customers. So much better to have fancy gizmos that show off your customer's broadband and annoy your customer's customers on flaky dialup. You much better to use scripts and effects to wow your customer while making the site unusable for your customer's customers who have the sense to kill those malware attractors.
It may be plain and simple, but if I have to mess with a lot of it, I think I'd find stuff done like his site much less irritating and wearing.
Cynic? I'm a product of society baby!
... and watch all our customers slowly jump ship to our competitors who do it native.
Ok, I'm an old fart and IMNSHO more cynical than you.
"We will just make the windows version and force the linux people to use Cedega if they want to use our stuff"
That's a short-term bridge. Only.
There is a difference between the "real thing" and "not exactly". It's slow. It's subtle. But it does matter.
I'm sorry but I fail to see how your idea of a cloud is better than a well organized file tree?
The well organized file tree is best assuming that you use the exact same tree to store the file as to access the file. Problems are that well organized doesn't come cheap and that the optimum tree structure changes over time. Add to that the fact that you really want the ability to recover information from files based on entirely different criteria than those used to initially store the file. The cloud is not a mechanism for finding stuff, it is the initial starting point from which he wants to be able to find stuff.
Longhorn will make more extensive use of them, I'm certain
Ditto the viruses.
numbers in identifiers -- the obvious I1 I2 J1 J2 A3PJ7Q
;-)
$ @ % to distinguish data types -- particularly if they occupy different name-spaces. Much cleaner if $foo @foo %foo co-exist and are handled differently.
contrived data naming scheme -- Mathematics and Engineering tend to love single-character names. They've been in the business for a long time. I suspect they know something about keeping your head straight when facing complexity. It helps immensely when something that is different looks different.
If the project is small enough, anything that distinguishes "this" from "that" will do nicely. When the project is large, something systematic must be done so that someone who has never seen the code or the variables before knows exactly what they represent. I suspect that something like hungarian notation manages to be exact on what doesn't matter at the expense of sloppiness on what does matter
You can't operate a business without money, so if people can just come along and steal your ideas, you're screwed. Some people innovate for genuine interest because they are already independently wealthy and can afford to not make money, the same is not true for corporations, who have shareholders to report to.
Question. Is Seagate making all they money from spam that they could? If not, why not?
You can't operate a business without money. True.
So if people can just come along and steal your ideas, you're screwed. Doesn't follow. If they can take the ideas and deprive you of your use of them, then probably so. If your business depends on you being the only one with ideas then it holds. In the world of high fashion, where the ideas matter very much, people can and do "just come along and steal your ideas." I don't think the high-fashion designers are going broke.
Corporations are responsible to their shareholders. And to their employees and to their customers and to their suppliers and to the comumities in which they operate.
What unique attributes of perl do you believe contribute to your claim that perl "can become unmaintainable on a small project"?
Hardly unique, but it uses letters and numbers and some special characters for identifiers and other stuff. The way these are/can be used allows perl (or any other language) to become unmaintainable on a small project. With adequate care of assinging identifiers it would be possible to maintain very large projects using old FORTRAN 6-character name space. I'm sure it would also be possible to build large, complicated, dynamic systems in COBOL.
Sound inefficient, sure, but it works like a champ
Efficiency is always a matter of never being too inneficient for the context. Basically, you have a certain amount of time in which to do whatever it is you need to do. Faster isn't really any better, but slower always hurts.
Instead of doing that, why not learn how to use the dbms the way it was intended to be used, natively? Learn SQL well, not as a metaphor for objects. Learn how to optimize queries; don't just throw in some caching layer on top of your slow SQL queries and pretend you've solved anything. Instead, all you done is trade data freshness for speed, badly, and introduced state into your app server.
Probably the best advice in this whole mess.
All that matters is that it will work with higher demand. Who cares how or why.
...] methinks is the correct word, whether or not anyone else has previously used it. "subjective" would also work but gives a much weaker meaning to the sentence. You can make the term "scalable" mean what you want/need it to mean. I can ditto independently.
Completely correct until you have to figure out whether or not it is scalable, for your required definition of scalable.
"subjectable" [can be made subject to
I think in general it means that within the expected range of increased load, the costs, etc are essentially linear. Traffic jams are a ubiquitous example of non-scaleable traffic systems. You reach a point where changes in results are all out of proportion to changes in inputs.
I remember the difference between that early Excel and Lotus, too. Lotus had more checklist features for a long time, but Excel -- it was just plain beautiful and fun to use.
WYSIWYG attempts by Lotus never did really work very well.
Most spreadsheets are just a tabular presentation of some data with maybe a wee bit of calculation, and most of that calculation is simulating a 10-key adding machine.
You're very right. Marketing and Sales are very different creatures and quite often have nothing to do with each other.
If you accidentally import the bank data twice, both packages will happily post it twice, and you'll spend an hour removing the double posts. That's not support. [Emphasis added]
From what I have seen, that is support. That seems to match anyone's definition of whether they support something or not. I have even seen a case where something was supported by turning off that something.
I think that "supported" really only means that it is acceptable help-desk fodder. Totally unrelated to whether or not it works or how well.
Now what supported should mean, I gotta agree with you.
But if you go by what it should mean, OpenBSD is user-friendly and Microsoft Windows is not user-friendly.
we had rackmount Pc's that would have almost 1/4 inch of metal/sand dust on the motherboards and the computers were STILL working.
Contacts that are exposed to a "harsh" environment generally form a very thin non-conductive film due to oxidation and/or corosion. This would also apply to any conductive surfaces. Depending on exactly what gets laid down, what you describe seems completely reasonable. However, something in a "clean" environment can easily be killed by something your self-protected PCs wouldn't even notice.
I suppose in the mean time we'll have to do our own safeguarding if we are in a risky area.
Hmmmm, seems like if you wanted to grow something like zink whiskers, you'd want a nice stable environment, free of foreign contaminants, and time, lots of time. From this standpoint, a dusty garage is a safer environment than a carefully controlled data center. Problems with monocultures.
What drug was the IE design team engineers taking when they decided to to let (or at least failed to prevent) untrusted program execution?
Assuming several layers in the hierarchy, the goons in the trenches are designing and coding to make themselves look better to their superiors who in turn are trying to impress their superiors. The old game of "gossip" applies, and even if common sense exists somewhere in the hierarchy, it will be blunted in favor of something, anything that will impress the higher-ups. Superficial glitz will triumph over basic competence regardless of anyones' attempts otherwise.
The amount of eye-candy is not really a valid metric. If you're good, damned good, you can "get away with anything". The wannabes will be confused into thinking you're good because of the eye-candy whereas the reality is quite different. (Microsoft caters to the wanabe crowd. Just look at their ads;) Run a good screen saver on a Linux Server, it's a cheap and effective way to monitor server health.
How about partials? Have they plugged any partials lately?
Only partially. (sorry about that;)
You could do what I do. Reboot and bring them all back up in the right order.
He had no idea which window contained what
Except that he does have a very good idea of which window is which.
It's subliminal, but they are laid down, left to right, in the same order that he opened them. With taskbar grouping, they're all there, but with no indication of which one is which.
kind of like cross-examining a Microsoft executive in court
or using Microsoft software. If it doesn't work the first time, try again, second or third try often works. Exactly the opposite behavior one expects from OpenBSD.
The old obsolete Techtronics 4014 had a display resolution of 4096 by 3072.
Not only was the display writable, it was also readable.
Progress?
How is BPL a bad idea? Aside from the problems that need to be worked out with interference with hobbists, this could be a legitimate alternative to dsl and cable.
Imagine running gigabit ethernet over silver-satin telephone wire.
Now imagine applying several thousand volts to the same wires.
The problems are not just with the hobbiests, they're just the first to notice because they happen to be interested in such things.
Assuming that crocodiles and dragon lizards (and probably vultures) have similar bad breath, T-Rex would almost certainly be also quite similar. The major ingredients would have to be chemicals given off by decomposing animal tissue. What T-Rex ate would matter more than anything else. The human nose is quite sensitive to (unacustomed) decomposition byproducts, enough so that Japanese find most westerners to have a very offensive body odor (from rotting hamburgers).
but "unknown" == "unknown" yes ?
No.
"unknown" == "unknown" no.
"unknown" != "unknown" no.
I think the semantics for NULL is that the row for that column value does not exist. NULL is not a value, it is a mechanism to indicate the lack of a place that would hold that value.
What you don't know has a way of messing up any and all grandiose plans.
;-(
He was right about one thing. Anything that is capable of being represented will most likely be represented. A good choice of representation can deprive an awful lot of nasty problems of any means of expressing themselves. Getting rid of "almost all" still leaves plenty
They simply believe that "nulls" are a hack around the real need of supporting full value domains.
Thanks, makes sense.
However, the required complexity required to handle "the real need of supporting full value domains" has to be sufficient to handle all possible reasons and scenarios where you do not have a simple value. You might get close with a Lisp back-end, but this is heading too much like needing a supercomputer to hand one number in an el-cheapo caculator.
Nulls are a hack. A nice simple hack. It is possible to build bigger and more complicated hacks and take things a wee bit further, but the further the screwier I'd expect.