I was actually strongly tempted to Foe you over this, but instead I'll argue with you.
From reading your various comments on this discussion, it appears that your premise is "the students are morally in the wrong because Stanford et al hadn't authorized the release of admissions data." I disagree, obviously.
Stanford released their admissions data to the site, presumably on the grounds that (a) the site not release it and (b) the university reserves the privilege of changing that data up until it is released.
A flaw in the site's code allowed unauthorized users to view the data. This is a failure of the web site; were I in any of the affected universities' legal departments I would be looking Very Hard at suing the site for what happened, as it displays a disregard for security and incompetence in the face of web technologies. As far as I'm concerned, that's the end of it: the site failed to properly secure data, and as a result that data was accessed by "unauthorized" parties.
However, from the students' point of view as users of a web application, the only authoritative reference for what information is 'allowed' is what information is reachable. It has never been true that "not releasing a URL" is sufficient to prevent access to the corresponding resource, and modifying URLs is a fairly normal thing for even slightly advanced users to do for no other reason than simple curiousity. Well-written web software must as a matter of course expect arbitrary URLs to be fed to it and should react consistently and appropriately; thus, it is normal to expect that information you can reach is information you're allowed to reach.
That's the crux of the matter. Stanford expected (perfectly rationally) the site to secure their "unreleased" data, while the site's users expected (perfectly rationally) that information reachable was information they should get. The only party that's morally in the wrong is the party that failed to uphold either of those expectations, as they have a contract with the universities to control access to information and an informal but well-documented set of expectations to satisfy for their users.
Stanford is free to reject applicants over this; they'll have to deal with the consequences of that action, including potential lawsuits and probable bad publicity. Describing the students as "morally wrong" for their actions is intellectually wrong.
Close, but still wrong. Muad'Dib's attack takes place during a sandstorm -- the massive ambient static charge from the sand flying about is what disables the shields. Normally this is something of a non-issue: the Shield Wall, a range of mountains basically surrounding the Arrakeen Spaceport and the surrounding land, pretty effectively prevents a land-based attack under normal circumstances, and an aerial attack rather relies on the air not being full of ornithopter-unfriendly sand.
Paul used his house atomics against the shield wall to create a breach in it for the Fremen raiders to ride their worms through, unleashing both Fremen vengeance and Shai-Hulud within the Arrakeen Basin. In the Dune universe the standing wisdom is that to use atomics against people would bring down the collective wrath of all the other houses, but Paul's creative use merely applied their destructive power to a fixed terrain feature. It made the other houses deeply uncomfortable, but as far as I can tell didn't bring down their immediate wrath.
You're right about the interaction between energy weapons (lasguns) and shields being destructive to both the lasgun and the shielded object -- though the effect is described as being wildly unpredictable, ranging from destroying just the gunner and the shielded area to a massive, nuclear-scale explosion.
(I can't believe I remember all of this. Damn you, Frank Herbert, give me back my neurons!)
Reading/dev/urandom does not block when the system runs low on entropy -- it just keeps producing "random" noise that gets less random. This property makes/dev/urandom unsuitable for real crypto use, where you want/dev/random's entropy guarantees.
Read the man page on random(4) for more info.
Exactly as easy as it is to crash an x86 with C. A real operating system (implied in "shell account", I think) prevents user programs from crashing the whole computer, regardless of the language the program was written in -- in fact, it doesn't care about languages, because all it sees is the resulting executables and libraries anyways, which might as well be assembler.
It's true enough that it's easy to write a program that crashes in assembler, but that's true of any other language, too.
If the OP is writing boot loaders, kernels, or any other "raw machine" code, then a shell account is certainly inappropriate and he should get real hardware to run his code on. If, as seems more likely, it's just "how to write some simple programs in assembler", a shell account with appropriate tools will work just fine.
Windows "still" sucks because it must, for business reasons, be as compatible as possible with applications written for previous versions of Windows. This means that if some random API is discovered to be badly designed, or insecure, or to have any other fault, it can't simply be removed. At best its functionality (not interface) can be updated to something more civilised, but if the functionality is broken and important applications depend on the broken behaviour, then business overrides technical objections and the broken behaviour stays.
Couple this with the mediocre review most of their development documentation recieves: there are examples in the MSDN docs where the code does something violently insecure or uses an outdated, replaced API either because it's "just an example" or because the example in question hasn't been revised since forever.
The BeOS philosophy of "throw it out and rebuild it when it gets too crufty" is a great idea, but from a business standpoint it's suicide. Microsoft understands this.
Lovely theory. Doesn't fly, though, at least for some companies. I'm a former phone tech for an ISP named after a desert bird -- the techs never knew whether any given call was being monitored and definitely never knew what the monitor crew overheard outside the tech's customer interaction.
Ugh. I still have nightmares about that job.
Right, and as pgsql is an open-source project, if you feel strongly enough about the default configurations and the installation instructions and so on, you're free to provide changes. I don't feel strongly enough about it; I'm personally very comfortable with PostgreSQL's configrations, and leave very little of it untouched from the defaults.
To be honest, the biggest issue with PostgreSQL that I see is the weakness of the introductory documentation. Learning how to add users, change authentication mechanisms (both how and why, and importantly why not), create databases, and so on is somewhat loosely explained; the docs have tutorials for users, which assume that the database is already set up and working, but no "cookbook"-style introduction for new server administrators.
I'm going to forgo the opportunity to mod this fascinating debate to discuss this. You mentionned that PostgreSQL was "an order of magnitude" slower on imports -- my guess is that your import tool simply connected and started running INSERTs? It's a common-ish trap for new users. If there is no transaction running, each statement is its own transaction, with all the BEGIN and COMMIT overhead that goes with it. Wrapping your import in a BEGIN;... COMMIT; pair would probably have sped it up considerably.
There is an option to change the transactionality of standalone commands, too, so that they implicitly start a transaction that doesn't end until you COMMIT it.
VACUUM is something of a contentious point among PostgreSQL users, certainly. On the one hand, I can't think of an algorithmic way to automatically schedule statistic updates, and apparently tracking them in real time causes more of a performance hit than is needed. On the other, having to set up an external task (either a cron task or vacuumd) rather than being able to configure postmaster to vacuum itself on a schedule or other parameters is kind of a pain.
PostgreSQL's default memory cache size is exceedingly small -- this is an issue with the default configuration that can lead to excessive disk reads and writes.
In short, pgsql does require somewhat more effort to initially configure and maintain. On the other hand, for a lot of people it's very much worth that effort.
This is one of those moments when I'd really like to be able to take posts back. On further consideration, durrr. CR LF makes perfect sense if your output device is a line printer, especially if it's a line printer evolved from a typewriter (so it, too, has the given CR LF behaviour).
Ah, the wonders of "backwards compatability". One has to wonder whether the IBM BIOS programmers were pulled from the team that built the Selectric or something...
I actually found out where DOS, thence Windows, got CR LF from the other day. I'm sure a number of people here are already aware, but I'm going to go ahead and share anyways.
The x86 BIOS video interrupt (int 10h) has a number of video options; one of them (AH = 0Eh) deals with writing characters to the screen in text (TTY) mode. When writing to the screen in raw assembler, you generally write something like
;;; Print the string at ds:si to the screen. puts:
cld
mov ah, 0Eh
mov bh, 00h
mov bl, 07h
.puts_loop
lodsb ; read a char out of the string into al
test al, al ; terminate on \0
jz.puts_done
int 10h ; print char
jmp.puts_loop
.puts_done
ret
(Which is a first-approximation implementation of the C 'puts' function, with a badly-broken calling convention.)
If you feed this function a string containing only a line feed, the cursor happily moves down a line but does not go back to column 0; the effect is rather like stairs, viewed from the side. The carriage return, which could just as easily have been after the newline, resets the cursor to column 0 but does not move down a line.
The PostgreSQL website is easy to navigate and easy on the eyes. Links to anything most users will need -- downloads, docs, and search -- are right at the top of every page.
The MySQL website uses microfonts, and good luck finding documentation without resorting to google site:mysql.com; there's links to it on some pages and not others, and most notably not on the front page. The MySQL website is, apparently, trying to be oracle.com, only worse.
The difference is pretty simple: The postgresql developers are trying to write a database server. Selling it is not their concern, nor is marketing it to the world: they let others (mostly, their users) do that while they focus on development. MySQL, on the other hand, is a business: they need customers to survive, and sometimes the technology takes a back seat to the business side of things.
Well-known ports are very problematic in that it assumes there are a fixed-number of protocols to assign standard ports to, and it assumes everyone is cooperating. By allowing the arbitrary identifiers to determine the port, you can drop "well known ports" altogether.
No, you don't. You simply move the problem from "well-known ports" to "well-known labels".
Lots of reasons, but the two main ones I can think of are: combined code base (as quality of code increases, it increases for all protocols) and it would make it easier to implement protocols and work with them. All the different internet protocols, while very similar, have their own little quirks.
Not all "internet protocols" are sufficiently similar to be wedged into a single, request-response-oriented protocol. Consider X11 (6000 + display #) or VNC (5800 + display #, 5900 + display #), for instance. Or IRC (6667), to pick something a little closer to the canonical set of 'core' (text-based) internet protocols. All of these protocols have been designed with a specific task in mind, and not one of them maps well to HTTP's request-response structure: they're all asynchronous.
You bought your distributions, so one of the things you paid for was support. Did you call SuSE's support line and get help? If not, why did you pay for a distribution?
Exactly. Microsoft is just being singled out because they are
making all this money. No software program, not even your
$FAVORITE_DISTRO, is foolproof. Holding software developers/companies
accountable is not feasible nor advisable. Best to let market decide
which ones to prosper and which ones to push to oblivion.
And what if we replace the appropriate nouns with Ford, utomobiles,
and automotive manufacturers? The problem is that consumers are not
and never will be knowledgeable enough to judge software
quality objectively, nor should they need to be. Lemon laws exist to
protect consumers from bad products that are too complex to be readily
understood.
Re:One example of why the tests are BS
on
Java Faster Than C++?
·
· Score: 2, Insightful
does essentially the same thing, but is less error-prone than an operator new/operator delete pair -- consider what happens if an exception occurs between your new and delete.
There's basically no reason to allocate a single object using new and delete it within the same scope. Allocating arrays, or allocating an object for use in a different scope, are okay.
The symbol you're looking for is, in fact, the swastika. It's not a Nazi invention; prior to their use of it it was a fairly universal symbol for luck and propsperity. The word 'swastika' is sanskrit for "it is good," generally interpreted as "good luck" or "well-being."
"In C++, all parameters are passed by value." Unless they're passed by reference, anyways.
If you want to get technical about it, a pass by reference is equivalent to passing a pointer(reference) by value. Think about the syntax of the declaration.
Consider:
/// A trivial swap implementation inline void Swap (int &a, int &b) { a ^= b^= a ^= b; }
While internally to the compiler a and b may be (and often are) pointers, that fact is hidden from the programmer and is in no way guaranteed. However, a and b are guaranteed to refer to valid, changeable ints. Furthermore, the call swap (foo, bar); will actually swap the contents of foo and bar in the calling function.
Ok, now having actually read the link, here is a list of things that are either actively wrong or totally unhelpful:
No mention of std::vector in the discussion of arrays
Deprecated pre-standard headers such as
#include <pair.h>
instead of
#include <pair>
Introduces C-style IO (printf et al) before stream IO, even though Java provides workable streams and C-style IO is completely nonestensible in ways a Java programmer may be accustomed to
To declare a constant in C++, you use #define (not final) as in:
#define MAX_SIZE 10
No. Please use const instances. They're typechecked but the compiler is free to translate them into inline constants similar to what the preprocessor produces:
const int MAX_SIZE = 10;
Macros (#define min(x,y) (((x)
void main (...) is totally wrong. Main is not permitted to be void in C++. Some compilers will allow it, but it is not a feature of the langugae.
C-style typedef struct {...} typename; is unnecessary in C++; structs essentially are handled as classes that default to public and as such the struct name is a type.
Unions.
"In C++, all parameters are passed by value." Unless they're passed by reference, anyways.
You do not need to use std::malloc to allocate a structure or a builtin type. The 'new' operator works just fine.
Christ. This is from 1998. No wonder it's got so many issues.
Not actually that useful. They don't mention smart pointers in the memory management section. They claim C++ has no string type. Not good.
But, to someone who knows Java and knows almost nothing about C++ (like me), it's a good start. True, it doesn't tell you EVERYTHING, but it's a start.
No. If the grandparent is right (I didn't check, of course) then it's not a good start. It teaches you things about the language that are actively wrong (that it has no string type) and doesn't teach you things that may make life a lot easier if you're coming from Java (self-managing pointers).
Slashdot Mirror
I was actually strongly tempted to Foe you over this, but instead I'll argue with you.
From reading your various comments on this discussion, it appears that your premise is "the students are morally in the wrong because Stanford et al hadn't authorized the release of admissions data." I disagree, obviously.
Stanford released their admissions data to the site, presumably on the grounds that (a) the site not release it and (b) the university reserves the privilege of changing that data up until it is released.
A flaw in the site's code allowed unauthorized users to view the data. This is a failure of the web site; were I in any of the affected universities' legal departments I would be looking Very Hard at suing the site for what happened, as it displays a disregard for security and incompetence in the face of web technologies. As far as I'm concerned, that's the end of it: the site failed to properly secure data, and as a result that data was accessed by "unauthorized" parties.
However, from the students' point of view as users of a web application, the only authoritative reference for what information is 'allowed' is what information is reachable. It has never been true that "not releasing a URL" is sufficient to prevent access to the corresponding resource, and modifying URLs is a fairly normal thing for even slightly advanced users to do for no other reason than simple curiousity. Well-written web software must as a matter of course expect arbitrary URLs to be fed to it and should react consistently and appropriately; thus, it is normal to expect that information you can reach is information you're allowed to reach.
That's the crux of the matter. Stanford expected (perfectly rationally) the site to secure their "unreleased" data, while the site's users expected (perfectly rationally) that information reachable was information they should get. The only party that's morally in the wrong is the party that failed to uphold either of those expectations, as they have a contract with the universities to control access to information and an informal but well-documented set of expectations to satisfy for their users.
Stanford is free to reject applicants over this; they'll have to deal with the consequences of that action, including potential lawsuits and probable bad publicity. Describing the students as "morally wrong" for their actions is intellectually wrong.
Close, but still wrong. Muad'Dib's attack takes place during a sandstorm -- the massive ambient static charge from the sand flying about is what disables the shields. Normally this is something of a non-issue: the Shield Wall, a range of mountains basically surrounding the Arrakeen Spaceport and the surrounding land, pretty effectively prevents a land-based attack under normal circumstances, and an aerial attack rather relies on the air not being full of ornithopter-unfriendly sand.
Paul used his house atomics against the shield wall to create a breach in it for the Fremen raiders to ride their worms through, unleashing both Fremen vengeance and Shai-Hulud within the Arrakeen Basin. In the Dune universe the standing wisdom is that to use atomics against people would bring down the collective wrath of all the other houses, but Paul's creative use merely applied their destructive power to a fixed terrain feature. It made the other houses deeply uncomfortable, but as far as I can tell didn't bring down their immediate wrath.
You're right about the interaction between energy weapons (lasguns) and shields being destructive to both the lasgun and the shielded object -- though the effect is described as being wildly unpredictable, ranging from destroying just the gunner and the shielded area to a massive, nuclear-scale explosion.
(I can't believe I remember all of this. Damn you, Frank Herbert, give me back my neurons!)
Reading /dev/urandom does not block when the system runs low on entropy -- it just keeps producing "random" noise that gets less random. This property makes /dev/urandom unsuitable for real crypto use, where you want /dev/random's entropy guarantees.
Read the man page on random(4) for more info.
Exactly as easy as it is to crash an x86 with C. A real operating system (implied in "shell account", I think) prevents user programs from crashing the whole computer, regardless of the language the program was written in -- in fact, it doesn't care about languages, because all it sees is the resulting executables and libraries anyways, which might as well be assembler.
It's true enough that it's easy to write a program that crashes in assembler, but that's true of any other language, too.
If the OP is writing boot loaders, kernels, or any other "raw machine" code, then a shell account is certainly inappropriate and he should get real hardware to run his code on. If, as seems more likely, it's just "how to write some simple programs in assembler", a shell account with appropriate tools will work just fine.
Windows "still" sucks because it must, for business reasons, be as compatible as possible with applications written for previous versions of Windows. This means that if some random API is discovered to be badly designed, or insecure, or to have any other fault, it can't simply be removed. At best its functionality (not interface) can be updated to something more civilised, but if the functionality is broken and important applications depend on the broken behaviour, then business overrides technical objections and the broken behaviour stays.
Couple this with the mediocre review most of their development documentation recieves: there are examples in the MSDN docs where the code does something violently insecure or uses an outdated, replaced API either because it's "just an example" or because the example in question hasn't been revised since forever.
The BeOS philosophy of "throw it out and rebuild it when it gets too crufty" is a great idea, but from a business standpoint it's suicide. Microsoft understands this.
Got a reference for that story?
Lovely theory. Doesn't fly, though, at least for some companies. I'm a former phone tech for an ISP named after a desert bird -- the techs never knew whether any given call was being monitored and definitely never knew what the monitor crew overheard outside the tech's customer interaction. Ugh. I still have nightmares about that job.
Right, and as pgsql is an open-source project, if you feel strongly enough about the default configurations and the installation instructions and so on, you're free to provide changes. I don't feel strongly enough about it; I'm personally very comfortable with PostgreSQL's configrations, and leave very little of it untouched from the defaults.
To be honest, the biggest issue with PostgreSQL that I see is the weakness of the introductory documentation. Learning how to add users, change authentication mechanisms (both how and why, and importantly why not), create databases, and so on is somewhat loosely explained; the docs have tutorials for users, which assume that the database is already set up and working, but no "cookbook"-style introduction for new server administrators.
I'm going to forgo the opportunity to mod this fascinating debate to discuss this. You mentionned that PostgreSQL was "an order of magnitude" slower on imports -- my guess is that your import tool simply connected and started running INSERTs? It's a common-ish trap for new users. If there is no transaction running, each statement is its own transaction, with all the BEGIN and COMMIT overhead that goes with it. Wrapping your import in a BEGIN; ... COMMIT; pair would probably have sped it up considerably.
There is an option to change the transactionality of standalone commands, too, so that they implicitly start a transaction that doesn't end until you COMMIT it.
VACUUM is something of a contentious point among PostgreSQL users, certainly. On the one hand, I can't think of an algorithmic way to automatically schedule statistic updates, and apparently tracking them in real time causes more of a performance hit than is needed. On the other, having to set up an external task (either a cron task or vacuumd) rather than being able to configure postmaster to vacuum itself on a schedule or other parameters is kind of a pain.
PostgreSQL's default memory cache size is exceedingly small -- this is an issue with the default configuration that can lead to excessive disk reads and writes.
In short, pgsql does require somewhat more effort to initially configure and maintain. On the other hand, for a lot of people it's very much worth that effort.
This is one of those moments when I'd really like to be able to take posts back. On further consideration, durrr. CR LF makes perfect sense if your output device is a line printer, especially if it's a line printer evolved from a typewriter (so it, too, has the given CR LF behaviour).
Ah, the wonders of "backwards compatability". One has to wonder whether the IBM BIOS programmers were pulled from the team that built the Selectric or something...
The x86 BIOS video interrupt (int 10h) has a number of video options; one of them (AH = 0Eh) deals with writing characters to the screen in text (TTY) mode. When writing to the screen in raw assembler, you generally write something like(Which is a first-approximation implementation of the C 'puts' function, with a badly-broken calling convention.)
If you feed this function a string containing only a line feed, the cursor happily moves down a line but does not go back to column 0; the effect is rather like stairs, viewed from the side. The carriage return, which could just as easily have been after the newline, resets the cursor to column 0 but does not move down a line.
Were you asleep in math class?
Strongly disagree.
The PostgreSQL website is easy to navigate and easy on the eyes. Links to anything most users will need -- downloads, docs, and search -- are right at the top of every page.
The MySQL website uses microfonts, and good luck finding documentation without resorting to google site:mysql.com; there's links to it on some pages and not others, and most notably not on the front page. The MySQL website is, apparently, trying to be oracle.com, only worse.
The difference is pretty simple: The postgresql developers are trying to write a database server. Selling it is not their concern, nor is marketing it to the world: they let others (mostly, their users) do that while they focus on development. MySQL, on the other hand, is a business: they need customers to survive, and sometimes the technology takes a back seat to the business side of things.
No, you don't. You simply move the problem from "well-known ports" to "well-known labels".
Not all "internet protocols" are sufficiently similar to be wedged into a single, request-response-oriented protocol. Consider X11 (6000 + display #) or VNC (5800 + display #, 5900 + display #), for instance. Or IRC (6667), to pick something a little closer to the canonical set of 'core' (text-based) internet protocols. All of these protocols have been designed with a specific task in mind, and not one of them maps well to HTTP's request-response structure: they're all asynchronous.
Please Do Not Throw Sausage Pizza Away. What can I say? Our class was made of hungry geeks.
You bought your distributions, so one of the things you paid for was support. Did you call SuSE's support line and get help? If not, why did you pay for a distribution?
And what if we replace the appropriate nouns with Ford, utomobiles, and automotive manufacturers? The problem is that consumers are not and never will be knowledgeable enough to judge software quality objectively, nor should they need to be. Lemon laws exist to protect consumers from bad products that are too complex to be readily understood.
That's not useful.
does essentially the same thing, but is less error-prone than an operator new/operator delete pair -- consider what happens if an exception occurs between your new and delete.
There's basically no reason to allocate a single object using new and delete it within the same scope. Allocating arrays, or allocating an object for use in a different scope, are okay.
The symbol you're looking for is, in fact, the swastika. It's not a Nazi invention; prior to their use of it it was a fairly universal symbol for luck and propsperity. The word 'swastika' is sanskrit for "it is good," generally interpreted as "good luck" or "well-being."
Some links:
Consider:
While internally to the compiler a and b may be (and often are) pointers, that fact is hidden from the programmer and is in no way guaranteed. However, a and b are guaranteed to refer to valid, changeable ints. Furthermore, the call swap (foo, bar); will actually swap the contents of foo and bar in the calling function.
Ok, now having actually read the link, here is a list of things that are either actively wrong or totally unhelpful:
No. Please use const instances. They're typechecked but the compiler is free to translate them into inline constants similar to what the preprocessor produces:
Christ. This is from 1998. No wonder it's got so many issues.
No. If the grandparent is right (I didn't check, of course) then it's not a good start. It teaches you things about the language that are actively wrong (that it has no string type) and doesn't teach you things that may make life a lot easier if you're coming from Java (self-managing pointers).
Turn off SQL Server in the Services panel until the patches are installed.