Well, I realize that in principle, "w" stood for word, but this wasn't really how it was used in Windows. I guess Microsoft was kinda sloppy, but basically I just thing the whole Hungarian notation, where you prefix the type of the variable to the variable is a terrible, ugly thing. Modern code editors like Emacs can automatically find the declaration of a variable for you. Plus in well written procedural code, most of your variables should be of a small enough in scope that finding the declaration is EASY.
In Windows 3.1 API, "w" meant 16-bit and "l" meant 32-bit integer. But then in Windows 95 API, "l" still meant 32-bit, and "w" was still no longer used.
Organizational charts only have to be read by humans. If there are nice boxes connected by lines, humans can figure them out. You can draw an org chart with crayons, blood, the GIMP, HTML, whatever.
Human beings are smart! We can see a picture and infer a structure (a correct structure, most of the time). Right now I can see a duck in a pond. It's all just a bitmap on my retina but my mind has figured out that the duck is separate from the water. Computers don't do this naturally.
Why has there been a push to go from HTML to XML? Originally HTML authors were encouraged to mark up things like italics and bold and links and line breaks and fonts and flashy things. Humans can easily read and write these, but it turns out that it's hard to get a computer to generally recognize bibliographies and titles and illustrations and spacers from these visual elements.
It is not easy for human beings and computers to communicate structure to one another. This is why programmers are conservative with what they will accept as source code. They want to keep it simple. Some of us are scared by Perl, because the parser is complex, so we don't know if the interpreter is parsing the code according to the spec, and we don't know if we're writing it to the spec.
The primary benefit of XML is that as a standardized language, standardized parsers can be made available that are reasonably easy to use.
A lot of comments have suggested that encapsulating source code in XML would make it easier to parse languages in a consistent fashion, and thereby to write better code validators, formatters, style checkers, etc.
This leads to a logical paradox: if programmers continue to write code in "plain" ascii format, how is it going to acquire the XML markup? Why, someone would have to write a parser, of course!
This XML encapsulation is a misguided effort to create a standard interface to code parsing. Guess what! A highly effective parser already exists for every single programming language. It's the compiler!
To encapsulate source code in an XML form that redundantly specifies how it is to be parsed is asking for trouble:
What if the XML markup ever gets out of sync with the plain text source code? Either:
Software for editing/validating/formatting the code WILL catch the problem. If so, that software must include a parser for the ASCII source code, thus rendering the XML useless, OR...
XML-ified software WILL NOT catch the problem. The code might get highlighted incorrectly in the editor or incorrectly validated by the code checker (yikes!)
What if compiler writers get lazy and start relying on the "pre-parsed" source code. Now the programmer might be in the lovely situation of editing plain text code that's marked up INCORRECTLY with *hidden* XML code that's affecting the compilation of the program.
My point is, don't include redundant information in the fundamental form of your source code, because it will get out of sync somehow. Remember all those wParam variables in 16-bit Windows API? The "w" was supposed to "document" that it's a 16 bit variable. Now it's declared as a 32-bit variable and everyone calls it wParam... if they still code in C. At worst, it's misleading, at best useless and annoying.
If people want a standard way to decipher language syntax, then compiler writers should write hooks in their compilers to export the parse tree in a standard format. Heck, it could even be an XML format, but this should be treated like an object file (it's derived from the source code rather than the source code itself).
I think that the MacOS X approach (which is similar to Windows, only cleaner) partly differs from the Linux/Unix approach because of a different software development philosophy.
Most Linux apps are open source (ok I run Debian so I'm biased). There's a strong emphasis on making things modular. Libraries are generally bundled separately from applications, because as soon as one app has a nifty feature it gets yoinked out and made into a general purpose library/API/framework (think GTK the "Gimp Toolkit").
Keeping libraries and apps separate fits in with the Linux goal of modularity which I believe is in a feedback loop with the open source philosophy.
OTOH, MacOS and Windows have a lot of proprietary closed apps. If Microsoft comes up with a new-fangled widget for Media Player, or Apple for iTunes, they don't need or want to make it particularly modular. They keep the support libraries close to the apps. A competing software company, say, MusicMatch, may reinvent the same widget and make their own library.
I think the Linux approach to program file organization fits better with open source. I do think that keeping all files for an app in one place has some advantages, for example making it easier to keep track of online help. Example: I hate when a gnome app can't find its own help files; these don't need to be used by multiple programs, and they can be replaced with every new version, so they should stay "close to the app" in my opinion.
Slashdot keeps on reporting these new copy protection schemes.
As everyone here knows, if the disc can be played in a CD player, a CDROM drive can be programmed to read it in the same way and extract the audio, yada yada yada. These systems are all the same.
I'm pretty sure that the RIAA is aware of the suckiness of these systems. They aren't that stupid. These systems will stop a decent number of clueless people from ripping CDs, and that's probably all they expect from them...
I think that a lot of splash screens are irritating, but some are useful when they give progress information! For example:
Gnome/KDE splash screens tell you about what components of the desktop are being loaded. Since you can't do anything until the desktop is loaded anyway, this isn't inconvenient. And if you're unhappy with the startup time, you'll have a rough idea of what components are taking longest to load.
Gimp splash screen: similarly gives you information on what components take a long time to load.
I think that these kinds of "progress bar" splash screens make sense only for large hefty apps that take a long to load, and tend to take up your whole screen when done. It would be incredibly annoying if, say, gnome-terminal had a splash screen.
Is this gonna be open source? If not, I predict it will have enough accompanying suckage to be not very usable. But if it is open source, cool!
Maybe there should be a new modifier...
on
Preview of KDE 3.4
·
· Score: 1
Maybe there should be another modifier, say something like "Verbatim" that can be attached to a post. This way useful copy/pasted text will get modded up so everyone can see it, but the poster won't get karma points.
There's nothing in the foreseeable future that will "kill" Linux. I'm not saying that some latest-greatest free OS wouldn't be adopted faster than Linux...
But when it comes down to it, what incentive is there to *stop using* Linux? High license costs? Nope, not for most users. Getting repeatedly burned by security problems? Nope, not if you keep it decently patched.
With Windows or other closed source OSs, there's often a financial incentive to actually *stop using* that OS. But if you run Linux and it works for you, and you have a support structure in place to maintain it, I can't see many reasons to actually bail.
Well, I read the French original and it states that any software licensed under the CeCILL license may be redistributed under the GPL, whether in modified or unmodified form. (section 5.3.4)
So basically, I think this means that a French developer could release software under CeCILL, then anyone can treat it as GPL software if it's more convenient for them. Very nice!
Is it even possible to build a stick shift hybrid car? Doesn't the onboard computer have to constantly adjust the amount of power coming from the gasoline engine and the electric batteries?
Maybe I don't understand how the drivetrain of a hybrid car works. Can anybody explain or give me some links?
Hehe... I'm dating a younger girl right now who's not at all a geek. We climb together a lot, and everywhere we go we meet other climbers who are engineers and scientists. It's starting to perplex her why there are so many of us climbing:-P
And I thought I had broken out of geekiness by riding a bike to work every day, and becoming an enthusiastic rock climber.
Thanks for destroying my illusions of normalcy, Slashdot!!!
How many Joe users out there?
on
JOE Hits 3.0
·
· Score: 1
This is great news. I have been using joe very happily since 1992, although I use Emacs for programming work generally. Joe is fast like VI and suprisingly powerful.
How many others have been quietly using Joe all these years?
until it detects connection attempts to closed ports 1026,1027,1029,1034,1026,1044 and 1035 in that sequence within 5 seconds, then listens on port 22 for a connection within 10 seconds.
What if you're connecting from, say, a spacecraft bound for Mars? Or what if you're just unlucky as hell and have a really slow noisy old modem connection. That arbitrary 10 second delay seems dumb.
Plus I think the whole idea isn't that interesting. It's just adding a new layer of "password" protection, essentially, in a modified form, with the dubious benefit of fooling currently existing port scanners, which will immediately be rewritten...
Why is it that 802.16 has vastly improved bandwidth and range compared to 802.11b/g?
Does it require special antennas and bulkier equipment? I imagine the power of the signal must be vastly greater... My 802.11b wireless card transmits at about 30 mW and with a very rudimentary antenna.
Slashdot Mirror
I agree. I don't like Microsoft's products very much, and I like their licensing and "compatibility" strategies even less...
But Bill Gates's charitable efforts are pretty awesome. Hard to disagree with anything there. He's doing a lot of good things with his money.
Well, I realize that in principle, "w" stood for word, but this wasn't really how it was used in Windows. I guess Microsoft was kinda sloppy, but basically I just thing the whole Hungarian notation, where you prefix the type of the variable to the variable is a terrible, ugly thing. Modern code editors like Emacs can automatically find the declaration of a variable for you. Plus in well written procedural code, most of your variables should be of a small enough in scope that finding the declaration is EASY.
In Windows 3.1 API, "w" meant 16-bit and "l" meant 32-bit integer. But then in Windows 95 API, "l" still meant 32-bit, and "w" was still no longer used.
Organizational charts only have to be read by humans. If there are nice boxes connected by lines, humans can figure them out. You can draw an org chart with crayons, blood, the GIMP, HTML, whatever.
Human beings are smart! We can see a picture and infer a structure (a correct structure, most of the time). Right now I can see a duck in a pond. It's all just a bitmap on my retina but my mind has figured out that the duck is separate from the water. Computers don't do this naturally.
Why has there been a push to go from HTML to XML? Originally HTML authors were encouraged to mark up things like italics and bold and links and line breaks and fonts and flashy things. Humans can easily read and write these, but it turns out that it's hard to get a computer to generally recognize bibliographies and titles and illustrations and spacers from these visual elements.
It is not easy for human beings and computers to communicate structure to one another. This is why programmers are conservative with what they will accept as source code. They want to keep it simple. Some of us are scared by Perl, because the parser is complex, so we don't know if the interpreter is parsing the code according to the spec, and we don't know if we're writing it to the spec.
This leads to a logical paradox: if programmers continue to write code in "plain" ascii format, how is it going to acquire the XML markup? Why, someone would have to write a parser, of course!
This XML encapsulation is a misguided effort to create a standard interface to code parsing. Guess what! A highly effective parser already exists for every single programming language. It's the compiler!
To encapsulate source code in an XML form that redundantly specifies how it is to be parsed is asking for trouble:
- What if the XML markup ever gets out of sync with the plain text source code? Either:
- Software for editing/validating/formatting the code WILL catch the problem. If so, that software must include a parser for the ASCII source code, thus rendering the XML useless, OR...
- XML-ified software WILL NOT catch the problem. The code might get highlighted incorrectly in the editor or incorrectly validated by the code checker (yikes!)
- What if compiler writers get lazy and start relying on the "pre-parsed" source code. Now the programmer might be in the lovely situation of editing plain text code that's marked up INCORRECTLY with *hidden* XML code that's affecting the compilation of the program.
My point is, don't include redundant information in the fundamental form of your source code, because it will get out of sync somehow. Remember all those wParam variables in 16-bit Windows API? The "w" was supposed to "document" that it's a 16 bit variable. Now it's declared as a 32-bit variable and everyone calls it wParam... if they still code in C. At worst, it's misleading, at best useless and annoying.If people want a standard way to decipher language syntax, then compiler writers should write hooks in their compilers to export the parse tree in a standard format. Heck, it could even be an XML format, but this should be treated like an object file (it's derived from the source code rather than the source code itself).
I think that the MacOS X approach (which is similar to Windows, only cleaner) partly differs from the Linux/Unix approach because of a different software development philosophy.
Most Linux apps are open source (ok I run Debian so I'm biased). There's a strong emphasis on making things modular. Libraries are generally bundled separately from applications, because as soon as one app has a nifty feature it gets yoinked out and made into a general purpose library/API/framework (think GTK the "Gimp Toolkit").
Keeping libraries and apps separate fits in with the Linux goal of modularity which I believe is in a feedback loop with the open source philosophy.
OTOH, MacOS and Windows have a lot of proprietary closed apps. If Microsoft comes up with a new-fangled widget for Media Player, or Apple for iTunes, they don't need or want to make it particularly modular. They keep the support libraries close to the apps. A competing software company, say, MusicMatch, may reinvent the same widget and make their own library.
I think the Linux approach to program file organization fits better with open source. I do think that keeping all files for an app in one place has some advantages, for example making it easier to keep track of online help. Example: I hate when a gnome app can't find its own help files; these don't need to be used by multiple programs, and they can be replaced with every new version, so they should stay "close to the app" in my opinion.
Slashdot keeps on reporting these new copy protection schemes.
As everyone here knows, if the disc can be played in a CD player, a CDROM drive can be programmed to read it in the same way and extract the audio, yada yada yada. These systems are all the same.
I'm pretty sure that the RIAA is aware of the suckiness of these systems. They aren't that stupid. These systems will stop a decent number of clueless people from ripping CDs, and that's probably all they expect from them...
- Gnome/KDE splash screens tell you about what components of the desktop are being loaded. Since you can't do anything until the desktop is loaded anyway, this isn't inconvenient. And if you're unhappy with the startup time, you'll have a rough idea of what components are taking longest to load.
- Gimp splash screen: similarly gives you information on what components take a long time to load.
I think that these kinds of "progress bar" splash screens make sense only for large hefty apps that take a long to load, and tend to take up your whole screen when done. It would be incredibly annoying if, say, gnome-terminal had a splash screen.Uh, yes it is... now. That's funny, the link wasn't in the story when I posted my original comment.
This article on LinuxDevices discusses the possibility of installing Linux on the PIC.
True, but many web client libraries (eg Perl's LWP) automatically handle GET redirects, so it depends what software lycos is using!
Is this gonna be open source? If not, I predict it will have enough accompanying suckage to be not very usable. But if it is open source, cool!
Maybe there should be another modifier, say something like "Verbatim" that can be attached to a post. This way useful copy/pasted text will get modded up so everyone can see it, but the poster won't get karma points.
Anyone admins reading?
OMG, this is going to revolutionize pr0n!
There's nothing in the foreseeable future that will "kill" Linux. I'm not saying that some latest-greatest free OS wouldn't be adopted faster than Linux...
But when it comes down to it, what incentive is there to *stop using* Linux? High license costs? Nope, not for most users. Getting repeatedly burned by security problems? Nope, not if you keep it decently patched.
With Windows or other closed source OSs, there's often a financial incentive to actually *stop using* that OS. But if you run Linux and it works for you, and you have a support structure in place to maintain it, I can't see many reasons to actually bail.
I find that SlashDot makes EXCELLENT bathroom reading. Thanks 802.11b!
Well, I read the French original and it states that any software licensed under the CeCILL license may be redistributed under the GPL, whether in modified or unmodified form. (section 5.3.4)
So basically, I think this means that a French developer could release software under CeCILL, then anyone can treat it as GPL software if it's more convenient for them. Very nice!
Is it even possible to build a stick shift hybrid car? Doesn't the onboard computer have to constantly adjust the amount of power coming from the gasoline engine and the electric batteries?
Maybe I don't understand how the drivetrain of a hybrid car works. Can anybody explain or give me some links?
Hehe... I'm dating a younger girl right now who's not at all a geek. We climb together a lot, and everywhere we go we meet other climbers who are engineers and scientists. It's starting to perplex her why there are so many of us climbing :-P
And I thought I had broken out of geekiness by riding a bike to work every day, and becoming an enthusiastic rock climber.
Thanks for destroying my illusions of normalcy, Slashdot!!!
This is great news. I have been using joe very happily since 1992, although I use Emacs for programming work generally. Joe is fast like VI and suprisingly powerful.
How many others have been quietly using Joe all these years?
Plus I think the whole idea isn't that interesting. It's just adding a new layer of "password" protection, essentially, in a modified form, with the dubious benefit of fooling currently existing port scanners, which will immediately be rewritten...
Why is it that 802.16 has vastly improved bandwidth and range compared to 802.11b/g?
Does it require special antennas and bulkier equipment? I imagine the power of the signal must be vastly greater... My 802.11b wireless card transmits at about 30 mW and with a very rudimentary antenna.
So what's different in 802.16?
I got a hat in the shape of a giant frog. It has big eyes that stick out and legs that stick out like a foot from your head. It's nuts.
:-P
It was a Chanukah present, actually
I'm (somewhat) lazy and also having trouble understanding these Diebold memos. Could someone summarize what they say that's so damning?
Too bad that Oskar Schindler wasn't Jewish, dumbass.