"Free speech" in US can be roughly described as a right to lie to the public. Being able to tell the truth is a side effect of it -- after all, American ideology recognizes truth as "one of the equally valid opinions" even if it describes observable facts.
I am not saying that teachers should not be paid a decent market wage.
The "market wage" for a public institution or government employee is zero -- there is no competition.
Teachers should be paid whatever is necessary to maintain educated society -- what is actually above typical private school teacher's salary, as those schools do not maintain such society in US, either. Libertarian windbags, however, should be paid their "market wage".
Until there will be a version of Windows where Windows compatibility layer is implemented on top of a Unixlike core, Windows is by definition crap. (Same applied to MacOS, but Apple released a Unixlike OS after all).
"Fraudulent" is the part where they claimed that Google service lacks certification.
Making such claims while not having certification themselves, is the "irresponsible" part, as bringing it up implies that Microsoft has it, and that is the reason why it is supposedly superior.
Renaming methods is not the same, really not even too similar, to "oops we were doing it wrong".
Moving them between classes and namespaces definitely is.
But I wonder, are you one of those folks who stubbornly refuses to fix bugs or implement feature requests, because your vast reserve of self-confidence has convinced you that your software is already perfect as-is?
No, I just carefully plan interfaces, so it's possible to change things without leaving greasy fingerprints all over the code that was working just fine, and was used by other people with whatever interface was originally provided by it.
No dude, get your head out of your ass, and stop being rude just for the sake of being rude.
I am being rude for the sake of emphasizing the incompetence and idiocy of my opponents, not for the sake of being rude.
Libc is the C standard library - and that, not any special awesomeness of its (no doubt quite skilled) developers is the reason is is so widely used.
Actually yes, it was. It was never intended to be as "standard" as it is, it just happened to be designed in a way that interface can stay the same without limiting the functionality. It also happened that it cleanly mapped to Unix system calls, another well-designed interface, but this is an example how interface can evolve without ruining compatibility or requiring massive rewrites. However it was quite popular on system that had absolutely nothing to do with Unix, never had C compiler ported from Unix, and among those on a few systems that should die in a fire due to their atrocious design.
Also it seems the developers of GNU libc (maybe you had a different implementation in mind?) did not decide on the names of its various function calls. Rather they implemented a variety of established standards (ANSI, POSIX, maybe others). Said standards were written over the course of years by dozens of very skilled people.
I am talking about libc interface, originally developed in early Unix, BSD and SysV. glibc is an implementation of that interface, and there are plenty of others, related or unrelated to glibc, BSD or SysV. In case of libc, standards actually are more of a description of "what should be implemented if one wants to make a Unix-like system". As the example of Microsoft's "POSIX subsystem" shows, someone who wants to write incompatible and unusable crap and still fit into the letter of the standard, will succeed doing so, therefore the role of formal standard document is secondary in this case.
I am sure, Russian government would have a problem if, say, all responses to email of some military contractor's employee ended up going unencrypted through routers where traffic is routinely intercepted by US government. The fact that even without any (supposedly illegal) interception Google will also inevitably collect statistics about the content and will probably "patriotically" turn the content to the US government if anything "interesting" will show up in statistics, is just icing on the cake.
Considering how all programming languages that use:= are hated with a passion, I would say that a swastika would make a better assignment operator by now.
The "sides" do not "agree" on anything. In Microsoft world one side produces an interface, and only a compatible implementation that uses a piece of code provided by the person who wrote the interface, and uses the same infrastructure, can safely use it.
Everyone else has the interface described in a human-readable manner -- one can refuse to look even at a single byte of code written by one side of the protocol, and be perfectly capable of communicating over it. There is no obligation to use the same infrastructure, the only thing that is required is understanding of the format, that is purposefully kept simple, so it can be a part of clearly designed interface. Servers, clients and peers can be replaced by different, unrelated implementations, and everything still works.
The idea of "object-oriented shell" is idiotic to begin with. Text can be parsed by anything, "objects" can only be handled by "objects" derived from them, turning software development into incest.
The whole idea of shell (and IPC, and network protocols, and even things like dbus) is to allow communications between completely unrelated pieces of software. Powershell design completely misses this (and underlying OS does not help, either).
So you don't see software design as an iterative process?
I see it as incremental process, not "oops, we were doing it wrong" process.
Libc is really not a great example. It is a widely distributed foundation library, upon which a vast multitude of other software is directly or indirectly dependent. The value of keeping interfaces constant in libc is thus much higher than the value of constant interfaces in the internal bits of your average application.
I think, you have placed cause and consequence backwards -- libc is widely used because it is well-designed. Why other projects are many orders of magnitude worse despite much simpler goals? Because their developers (including yourself) suck ass, that's why.
The fact that it's not true. As far as we can tell, origin or color of one's skin do not affect person's abilities -- social environment around him does.
I used minicom with sz to upload images over zmodem, however being Linux-based, device had sufficient resources to run another copy of rz. I did not need it after firmware got full Ethernet support, however then it was a nice way of updating chunks of flash without slow JTAG.
I guess, devices with serial-only bootloader would rather implement xmodem with the same software on the "terminal" side. C-Kermit in this way is worse than minicom -- it still requires external sz/rz but does not automatically start them when it sees a signature coming from the serial line. Kermit-95 apparently has built-in support for xmodem and zmodem, however I don't know how convenient it is. I have never seen actual Kermit protocol (built-in) used for anything other than testing between two boxes running Kermit.
Actually yes, a software developer has to have clear understanding what interface will be appropriate for components of his code when he implements it. It's called "software design".
It's either that, or rename things from time to time, or produce code with lots of somewhat-misleading method names.
Have you seen how many "somewhat-misleading" names are in, say, libc? They never ever were changed, thanks to the original Unix developers being somewhat good at software design.
Software interfaces (how parts of your software are connected to each other), not user interfaces (shit you see on the screen around text you are trying to edit).
BTW, you said the same thing I said about complexity, so you most be stupid too. Look into Visual Studio 2010's
I am not going to install Windows just to look at some Microsoft product's latest "features".
"Layer Validation" feature to see how an IDE can help manage complexity.
If you need an IDE to "manage complexity", something is seriously wrong with you code or with you. Visual Studio is a Microsoft product, and I would expect the leading crap-writers to develop their tools to deal with complexity in the crap they write -- but this is because they consistently avoid clean interfaces in everything they make. Everyone else is supposed to know better.
Slashdot Mirror
"Free speech" in US can be roughly described as a right to lie to the public. Being able to tell the truth is a side effect of it -- after all, American ideology recognizes truth as "one of the equally valid opinions" even if it describes observable facts.
No, he is Anonymous Coward. It is not clear if he reads anything (other the two words that he quoted, of course).
Estonia
Highest percentage of Hitler in population, too (higher than Germany and Austia!).
Oh wow.
...we will celebrate 50-year annivesary of Microsoft -- by removing Windows support from the last piece of still-maintained software.
I am not saying that teachers should not be paid a decent market wage.
The "market wage" for a public institution or government employee is zero -- there is no competition.
Teachers should be paid whatever is necessary to maintain educated society -- what is actually above typical private school teacher's salary, as those schools do not maintain such society in US, either. Libertarian windbags, however, should be paid their "market wage".
Windows 7
Until there will be a version of Windows where Windows compatibility layer is implemented on top of a Unixlike core, Windows is by definition crap.
(Same applied to MacOS, but Apple released a Unixlike OS after all).
"Fraudulent" is the part where they claimed that Google service lacks certification.
Making such claims while not having certification themselves, is the "irresponsible" part, as bringing it up implies that Microsoft has it, and that is the reason why it is supposedly superior.
Renaming methods is not the same, really not even too similar, to "oops we were doing it wrong".
Moving them between classes and namespaces definitely is.
But I wonder, are you one of those folks who stubbornly refuses to fix bugs or implement feature requests, because your vast reserve of self-confidence has convinced you that your software is already perfect as-is?
No, I just carefully plan interfaces, so it's possible to change things without leaving greasy fingerprints all over the code that was working just fine, and was used by other people with whatever interface was originally provided by it.
No dude, get your head out of your ass, and stop being rude just for the sake of being rude.
I am being rude for the sake of emphasizing the incompetence and idiocy of my opponents, not for the sake of being rude.
Libc is the C standard library - and that, not any special awesomeness of its (no doubt quite skilled) developers is the reason is is so widely used.
Actually yes, it was. It was never intended to be as "standard" as it is, it just happened to be designed in a way that interface can stay the same without limiting the functionality. It also happened that it cleanly mapped to Unix system calls, another well-designed interface, but this is an example how interface can evolve without ruining compatibility or requiring massive rewrites. However it was quite popular on system that had absolutely nothing to do with Unix, never had C compiler ported from Unix, and among those on a few systems that should die in a fire due to their atrocious design.
Also it seems the developers of GNU libc (maybe you had a different implementation in mind?) did not decide on the names of its various function calls. Rather they implemented a variety of established standards (ANSI, POSIX, maybe others). Said standards were written over the course of years by dozens of very skilled people.
I am talking about libc interface, originally developed in early Unix, BSD and SysV. glibc is an implementation of that interface, and there are plenty of others, related or unrelated to glibc, BSD or SysV. In case of libc, standards actually are more of a description of "what should be implemented if one wants to make a Unix-like system". As the example of Microsoft's "POSIX subsystem" shows, someone who wants to write incompatible and unusable crap and still fit into the letter of the standard, will succeed doing so, therefore the role of formal standard document is secondary in this case.
I am sure, Russian government would have a problem if, say, all responses to email of some military contractor's employee ended up going unencrypted through routers where traffic is routinely intercepted by US government. The fact that even without any (supposedly illegal) interception Google will also inevitably collect statistics about the content and will probably "patriotically" turn the content to the US government if anything "interesting" will show up in statistics, is just icing on the cake.
Considering how all programming languages that use := are hated with a passion, I would say that a swastika would make a better assignment operator by now.
The "sides" do not "agree" on anything. In Microsoft world one side produces an interface, and only a compatible implementation that uses a piece of code provided by the person who wrote the interface, and uses the same infrastructure, can safely use it.
Everyone else has the interface described in a human-readable manner -- one can refuse to look even at a single byte of code written by one side of the protocol, and be perfectly capable of communicating over it. There is no obligation to use the same infrastructure, the only thing that is required is understanding of the format, that is purposefully kept simple, so it can be a part of clearly designed interface. Servers, clients and peers can be replaced by different, unrelated implementations, and everything still works.
No one, actually. This is why keys are secret -- once they are disclosed, Sony has no legal way to assert any control over them.
This is like all Microsoft shills' tactics superimposed on each other.
Die in a fire.
>Anonymous
>Facebook
lol
Ever tried to edit a text document ob a touchscreen?
The idea of "object-oriented shell" is idiotic to begin with. Text can be parsed by anything, "objects" can only be handled by "objects" derived from them, turning software development into incest.
The whole idea of shell (and IPC, and network protocols, and even things like dbus) is to allow communications between completely unrelated pieces of software. Powershell design completely misses this (and underlying OS does not help, either).
So you don't see software design as an iterative process?
I see it as incremental process, not "oops, we were doing it wrong" process.
Libc is really not a great example. It is a widely distributed foundation library, upon which a vast multitude of other software is directly or indirectly dependent. The value of keeping interfaces constant in libc is thus much higher than the value of constant interfaces in the internal bits of your average application.
I think, you have placed cause and consequence backwards -- libc is widely used because it is well-designed. Why other projects are many orders of magnitude worse despite much simpler goals? Because their developers (including yourself) suck ass, that's why.
then what's the problem?
The fact that it's not true. As far as we can tell, origin or color of one's skin do not affect person's abilities -- social environment around him does.
I used minicom with sz to upload images over zmodem, however being Linux-based, device had sufficient resources to run another copy of rz. I did not need it after firmware got full Ethernet support, however then it was a nice way of updating chunks of flash without slow JTAG.
I guess, devices with serial-only bootloader would rather implement xmodem with the same software on the "terminal" side. C-Kermit in this way is worse than minicom -- it still requires external sz/rz but does not automatically start them when it sees a signature coming from the serial line. Kermit-95 apparently has built-in support for xmodem and zmodem, however I don't know how convenient it is. I have never seen actual Kermit protocol (built-in) used for anything other than testing between two boxes running Kermit.
Actually yes, a software developer has to have clear understanding what interface will be appropriate for components of his code when he implements it. It's called "software design".
It's either that, or rename things from time to time, or produce code with lots of somewhat-misleading method names.
Have you seen how many "somewhat-misleading" names are in, say, libc? They never ever were changed, thanks to the original Unix developers being somewhat good at software design.
gb2/b/
Software interfaces (how parts of your software are connected to each other), not user interfaces (shit you see on the screen around text you are trying to edit).
Am I ugly too?
I don't know.
BTW, you said the same thing I said about complexity, so you most be stupid too. Look into Visual Studio 2010's
I am not going to install Windows just to look at some Microsoft product's latest "features".
"Layer Validation" feature to see how an IDE can help manage complexity.
If you need an IDE to "manage complexity", something is seriously wrong with you code or with you. Visual Studio is a Microsoft product, and I would expect the leading crap-writers to develop their tools to deal with complexity in the crap they write -- but this is because they consistently avoid clean interfaces in everything they make. Everyone else is supposed to know better.
(actually a legitimate question)