While mailboxes themselves are stardard mbox files, thunderbird (& mozilla mail) do use a database (of sorts) for index information. It's called mork, and its supposed to combine the benefits of a transactional database with those of a straight text file. Unfortunately, some would say it accomplishes neither.
The C macro does the same thing. The only difference is that the string used with the C macro has an embedded nul character which the C++ string doesn't.
What matters is how we interpret the string. In C, by convention, the end of the string is taken to be the first nul character. In the C++ example, the length is explicitly provided. In both cases, the full text (probably) appears in the object code, but the program is instructed to only look at the first three characters.
I won't argue that C strings don't cause a lot of problems, but that is isn't relevant to this issue. One could just as easily create a counted string for the same purpose:
Is there a PDF version of this without the little targets in each corner of every page? Or some way to print it out without these unsightly distractions? Or an RTF version that has the diagrams?
This book looks really nice, but I find those little circles everywhere distracting when I print it out.
It's a case of supply and demand. Currently, there is a worldwide demand for US dollars from the reserve each country maintains to buy oil. If oil starts being sold in Euros, they no longer have to keep US dollars; they need Euros instead. A lot of those dollars sitting in foreign reserve vaults around the world would be sold off and return to the US. This would likely cause the US money supply to grow, which in turn would cause inflation.
The situation could snowball if the dollar loses too much value, and it loses it's status as the world's defacto hard currency.
Futures/Markets have been around for 500 so years. An investment/stock market is a relativly new invention.
The first stock market, specializing in equity in joint-stock companies, was founded in Antwerp in the late 1400s. Not so new. The first major crash was the South Sea Bubble of 1711.
Stock markets arose mainly to provide a means to raise capital for the growing number of import/export operations that were to expensive and/or risky for one person to finance.
You're buying a stock hoping someone will buy it for more money.
No, you are buying a piece of a company you hope will grow and be worth more later. Companies could offer stock, grow, sell off their assets and pay off their investors. But why shut down a successful business? That many companies retain profits to grow rather pay out dividends is irrelevent to the value of a stock, its just practical since profitability usually increases as economies scale.
there's not much use to owning stock
Sure there is: you think the company can use your money better than you can. You can put it in the bank and earn a measly 2% interest (and let the bank invest it), or you can give it to a company to invest in a new factory or writing software, hoping it will do better. Given that the stock market outperforms most other types of investment over very long periods suggests it works, too.
You say people will stop investing, because they suddenly realize they only have a piece of paper. I suppose we'll all withdraw our money from the banks and convert our cash into gold bullion, too. Why? What has changed?
Stock markets have been around for over 500 years in pretty much the same form. All thats changed is the diversity of the stock thats traded, the accessibility of markets to those with small amounts of capital, and the efficiency of the trades.
The assertion that the stock market will go away, or that it will change so much that gaining experience with it is a waste of time, is pretty bold, given that it goes against all historical precedent. Care to back up this claim with some kind of explaination?
The Java 1.2 JVM has incompatibilites with earlier versions. That is to say, bytecode compiled with a 1.2 javac wouldn't necessarily run on a 1.1 jvm. So think of it as Java Platform 2.
Java 1.5 bytecode is fully backwards compatible with 1.4 JVMs and 1.4 bytecode was backward with 1.3 JVMs (asserts would only cause library issues). I'd expect Java 3 to appear only if the JVM bytecode spec changes.
With C99, the most recent revision of the C standard, they added a new keyword restrict, to make "restricted" pointers. Basically, by using this new feature, it is possible to write code in C that is as easy to vectorize as Fortran.
Of course, its available only in recent compilers (gcc 3 for example) that may or may not be as good at this type of optimizing as Fortran compilers, but hopefully this argument for starting new development in Fortran can finally be put to rest.
Actually, in early iterations, gcc killed most vendor's compilers, including Sun's. This was mostly because most vendors's compilers were absolutely terrible when gcc was first released. Since then, compiler technology has made huge advances and vendors have spent lots of effort improving them. At the same time, with the increasingly complex scheduling requirements of todays RISC processors, making a compiler fast takes a lot more work. Designing a portable instruction scheduler that performs good on very different processors is nearly impossible (though gcc does it surprisingly well).
I'm surprised that mDNS wasn't mentioned in the context of the future of DNS. It is, after all, the technology behind Rendezvous, Apple's protocol for automatic service advertising and configuration on local LANs. mDNS is basically just normal DNS multicasted, with some conventions on how to represent services.
mDNS is already used for zero-configuration networking, sharing iTunes playlists, and finding other iChat users on a local LAN. Since it's based on DNS, its both simple and has mature implementations. And it's open source; Apple provides a working reference implementation for MacOS 9, MacOS X, Windows, and Posix (including Linux).
While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0. It more or less solves the 80% most common client-side validation tasks without adding a lot of complexity. This is a standard that will be intuitive to the average web developer, who is likely to be able to use it properly with a minimum of fuss. XForms is hugely compilicated in comparison, though it does solve a much bigger problem.
Additionally, according to an Opera developer, Webforms 2.0 has a good chance of being implemented in web browsers (meaning Opera and mozilla, I'd guess).
Windows "Execution Protection" is closer to the exec-shield feature in recent Linux kernels. Unlike the Windows technology, exec-shield exploits the existing hardware and works on all processors, but it isn't a 100% solution.
As I recall it, exec-shield maps most dynamically allocated memory in non-executable memory, and it places all the static allocations in the lower addresses that can't be represented as an ASCII string due to embedded nul characters.
The Windows feature just uses turns on a flag thats been added into the silicon for the same purpose.
The problem here isn't the strength of the encryption. The problem is that with crypt() there is only a two byte salt limited to certain characters, so each password maps to at most 4096 different passwords. Many unix systems use a newer system that allows up to eight arbitrary characters in the salt, which means any given password can map to 2 ^ 64 different hashes. It is this expanded salt that fixes crypt()'s most glaring problem.
While they're at it, they could do even more tweaking to reduce bandwidth and speed up page loads.
For example, they could put static content (side bar with Help, Stories, About, etc., bottom bar with home, awards, etc.) into seperate iframes. Then they'll get cached as static data, too. Adding Expires: and/or Cache-control: public, max-age=x HTTP headers to images, stylesheets and other static elements would explicitly flag them as static and cacheable. Finally, they could convert all their GIFs to PNGs, which are typically slightly smaller.
You have a point. I've seen examples of good flash pages. Flash applications, even.
But the fact remains that a large proportion of the flash I encounter is either advertising or superfluous animation. And very commonly, they are very visually distracting; so much so that they ruin the browsing experience. I've actually covered certain pieces of flash with other windows to avoid the distraction while trying to absorb the actual content of the page. Most of my experiences with flash are negative, not positive.
The solution, in my opinion, is not to remove the plugin altogether. I'd like to see web browsers to give the user better control over over their browser experience. For example, why not a option to start flash animations paused? Why does the plugin allow the flash to remove the pause option from the context menu?
Fortunately, there is a good comprimise available for mozilla at http://www.squarefree.com/userstyles/xbl.html as I've posted elsewhere already.
I wholeheartedly agree. I recommend this solution for mozilla users though: http://www.squarefree.com/userstyles/xbl.html
It shows a place holder in each flash frame until you click on it to play the flash. This gives you the best of both worlds: flash is blocked by default, but where you actually want to see it, it is only a mouse click away.
YMMV, but I regularly write non-ASCII accented characters in ssh sessions to a Linux box using PuTTY 0.53b. Sorry, I don't use telnet -- Windows or otherwise -- at all, so I shouldn't comment on it. Here is how I do it:
My $LANG on the Linux box is set to "en_US.UTF-8" and in the PuTTY configuration dialog under Window/Translation, I've set "Character set translation on received data" to UTF-8. I use the International keyboard driver to enter non-ASCII characters. This seems to do it.
As for Linux-to-Linux ssh, when the $LANG is the same on both ends, it seems to work fine. I use the emacs latin-1-prefix input method to enter non-ASCII characters here (I'm not sure how to do it from the console or an xterm directly, as I generally use emacs shell-mode, which works well both in console mode or in X11).
My WXP desktop usually has 1 or 2 Windows consoles and 1 or 2 telnet sessions to Linux servers open. But it sounds like telnetting into Fedora will be useless. One has to open an xterm in it's GUI to be able to use accents?
A linux console and a telnet session into a linux box are two very different things. The linux console is the text mode screen you see sitting down at the keyboard (or optionally a serial terminal) of a linux machine. While some people refer to any command-line session as a "console" session, this is inaccurate.
If you are using Windows telnet, you can enter non-ASCII characters as normal: switch to an international keyboard layout and type them as normal.
As an aside, you'd be wise to switch from telnet to ssh though.
It looks like XAML uses its own style system, different and incompatible to CSS.
The other major difference appears that while any.NET language can be used for the code bindings, they have to be compiled, unlike XUL/Javascript. This seems to suggest remote, browser-based XAML applications won't be possible, although IE can be used to preview the XAML layout.
But it does at least show MS thinks an XML interface description language ala XUL or MacOS X NIB(?) is the direction of the future.
So long as all those Windows licenses are paid for
Thats exactly it. A huge number of Windows licenses are bought and paid for when a computer is purchased. MS has a nice lock on OEMs which forces compliance. If running multiple instances of Windows on a computer takes off, then suddenly MS no longer has any leverage to force users to buy the extra licenses.
Because it is possible to write an insecure program in Linux, Linux is less secure? What a total non-sequitur.
It is trivial to write the above program in any language on any platform; that has absolutely nothing to do with an operating system's security.
What you will notice, though, is that with most Linux/Apache setups, $input will run as user "nobody" or "apache", with very few privileges, so an additional local root exploit would be necessary to do real damage. Unix was designed from the start to allow untrusted users to run programs locally. Its also worth noting that some Windows services can be locked down the same way, but in general, a remote exploit on a Windows box will almost always give you Administrator access.
Slashdot Mirror
While mailboxes themselves are stardard mbox files, thunderbird (& mozilla mail) do use a database (of sorts) for index information. It's called mork, and its supposed to combine the benefits of a transactional database with those of a straight text file. Unfortunately, some would say it accomplishes neither.
The C macro does the same thing. The only difference is that the string used with the C macro has an embedded nul character which the C++ string doesn't.
What matters is how we interpret the string. In C, by convention, the end of the string is taken to be the first nul character. In the C++ example, the length is explicitly provided. In both cases, the full text (probably) appears in the object code, but the program is instructed to only look at the first three characters.
Different ways of accomplishing the same thing.
I won't argue that C strings don't cause a lot of problems, but that is isn't relevant to this issue. One could just as easily create a counted string for the same purpose:
std::string licence("GPL, but not really", 3);
Is there a PDF version of this without the little targets in each corner of every page? Or some way to print it out without these unsightly distractions? Or an RTF version that has the diagrams?
This book looks really nice, but I find those little circles everywhere distracting when I print it out.
It's a case of supply and demand. Currently, there is a worldwide demand for US dollars from the reserve each country maintains to buy oil. If oil starts being sold in Euros, they no longer have to keep US dollars; they need Euros instead. A lot of those dollars sitting in foreign reserve vaults around the world would be sold off and return to the US. This would likely cause the US money supply to grow, which in turn would cause inflation.
The situation could snowball if the dollar loses too much value, and it loses it's status as the world's defacto hard currency.
Ever tried installing Java and Java programs?
Yes, I added jpackage.org to my sources.list and ran "apt-get install ant struts tomcat5" and got everything I needed.
Futures/Markets have been around for 500 so years. An investment/stock market is a relativly new invention.
The first stock market, specializing in equity in joint-stock companies, was founded in Antwerp in the late 1400s. Not so new. The first major crash was the South Sea Bubble of 1711.
Stock markets arose mainly to provide a means to raise capital for the growing number of import/export operations that were to expensive and/or risky for one person to finance.
You're buying a stock hoping someone will buy it for more money.
No, you are buying a piece of a company you hope will grow and be worth more later. Companies could offer stock, grow, sell off their assets and pay off their investors. But why shut down a successful business? That many companies retain profits to grow rather pay out dividends is irrelevent to the value of a stock, its just practical since profitability usually increases as economies scale.
there's not much use to owning stock
Sure there is: you think the company can use your money better than you can. You can put it in the bank and earn a measly 2% interest (and let the bank invest it), or you can give it to a company to invest in a new factory or writing software, hoping it will do better. Given that the stock market outperforms most other types of investment over very long periods suggests it works, too.
You say people will stop investing, because they suddenly realize they only have a piece of paper. I suppose we'll all withdraw our money from the banks and convert our cash into gold bullion, too. Why? What has changed?
Stock markets have been around for over 500 years in pretty much the same form. All thats changed is the diversity of the stock thats traded, the accessibility of markets to those with small amounts of capital, and the efficiency of the trades.
The assertion that the stock market will go away, or that it will change so much that gaining experience with it is a waste of time, is pretty bold, given that it goes against all historical precedent. Care to back up this claim with some kind of explaination?
There was a project to make a low resources mozilla called minimo. There is a webpage here, but I'm not sure how active the project is now.
The Java 1.2 JVM has incompatibilites with earlier versions. That is to say, bytecode compiled with a 1.2 javac wouldn't necessarily run on a 1.1 jvm. So think of it as Java Platform 2.
Java 1.5 bytecode is fully backwards compatible with 1.4 JVMs and 1.4 bytecode was backward with 1.3 JVMs (asserts would only cause library issues). I'd expect Java 3 to appear only if the JVM bytecode spec changes.
With C99, the most recent revision of the C standard, they added a new keyword restrict, to make "restricted" pointers. Basically, by using this new feature, it is possible to write code in C that is as easy to vectorize as Fortran.
Of course, its available only in recent compilers (gcc 3 for example) that may or may not be as good at this type of optimizing as Fortran compilers, but hopefully this argument for starting new development in Fortran can finally be put to rest.
Actually, in early iterations, gcc killed most vendor's compilers, including Sun's. This was mostly because most vendors's compilers were absolutely terrible when gcc was first released. Since then, compiler technology has made huge advances and vendors have spent lots of effort improving them. At the same time, with the increasingly complex scheduling requirements of todays RISC processors, making a compiler fast takes a lot more work. Designing a portable instruction scheduler that performs good on very different processors is nearly impossible (though gcc does it surprisingly well).
I'm surprised that mDNS wasn't mentioned in the context of the future of DNS. It is, after all, the technology behind Rendezvous, Apple's protocol for automatic service advertising and configuration on local LANs. mDNS is basically just normal DNS multicasted, with some conventions on how to represent services.
mDNS is already used for zero-configuration networking, sharing iTunes playlists, and finding other iChat users on a local LAN. Since it's based on DNS, its both simple and has mature implementations. And it's open source; Apple provides a working reference implementation for MacOS 9, MacOS X, Windows, and Posix (including Linux).
While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0. It more or less solves the 80% most common client-side validation tasks without adding a lot of complexity. This is a standard that will be intuitive to the average web developer, who is likely to be able to use it properly with a minimum of fuss. XForms is hugely compilicated in comparison, though it does solve a much bigger problem.
Additionally, according to an Opera developer, Webforms 2.0 has a good chance of being implemented in web browsers (meaning Opera and mozilla, I'd guess).
Windows "Execution Protection" is closer to the exec-shield feature in recent Linux kernels. Unlike the Windows technology, exec-shield exploits the existing hardware and works on all processors, but it isn't a 100% solution.
As I recall it, exec-shield maps most dynamically allocated memory in non-executable memory, and it places all the static allocations in the lower addresses that can't be represented as an ASCII string due to embedded nul characters.
The Windows feature just uses turns on a flag thats been added into the silicon for the same purpose.
The problem here isn't the strength of the encryption. The problem is that with crypt() there is only a two byte salt limited to certain characters, so each password maps to at most 4096 different passwords. Many unix systems use a newer system that allows up to eight arbitrary characters in the salt, which means any given password can map to 2 ^ 64 different hashes. It is this expanded salt that fixes crypt()'s most glaring problem.
While they're at it, they could do even more tweaking to reduce bandwidth and speed up page loads.
For example, they could put static content (side bar with Help, Stories, About, etc., bottom bar with home, awards, etc.) into seperate iframes. Then they'll get cached as static data, too. Adding Expires: and/or Cache-control: public, max-age=x HTTP headers to images, stylesheets and other static elements would explicitly flag them as static and cacheable. Finally, they could convert all their GIFs to PNGs, which are typically slightly smaller.
You have a point. I've seen examples of good flash pages. Flash applications, even.
But the fact remains that a large proportion of the flash I encounter is either advertising or superfluous animation. And very commonly, they are very visually distracting; so much so that they ruin the browsing experience. I've actually covered certain pieces of flash with other windows to avoid the distraction while trying to absorb the actual content of the page. Most of my experiences with flash are negative, not positive.
The solution, in my opinion, is not to remove the plugin altogether. I'd like to see web browsers to give the user better control over over their browser experience. For example, why not a option to start flash animations paused? Why does the plugin allow the flash to remove the pause option from the context menu?
Fortunately, there is a good comprimise available for mozilla at http://www.squarefree.com/userstyles/xbl.html as I've posted elsewhere already.
I wholeheartedly agree. I recommend this solution for mozilla users though: http://www.squarefree.com/userstyles/xbl.html
It shows a place holder in each flash frame until you click on it to play the flash. This gives you the best of both worlds: flash is blocked by default, but where you actually want to see it, it is only a mouse click away.
YMMV, but I regularly write non-ASCII accented characters in ssh sessions to a Linux box using PuTTY 0.53b. Sorry, I don't use telnet -- Windows or otherwise -- at all, so I shouldn't comment on it. Here is how I do it:
My $LANG on the Linux box is set to "en_US.UTF-8" and in the PuTTY configuration dialog under Window/Translation, I've set "Character set translation on received data" to UTF-8. I use the International keyboard driver to enter non-ASCII characters. This seems to do it.
As for Linux-to-Linux ssh, when the $LANG is the same on both ends, it seems to work fine. I use the emacs latin-1-prefix input method to enter non-ASCII characters here (I'm not sure how to do it from the console or an xterm directly, as I generally use emacs shell-mode, which works well both in console mode or in X11).
Hope this helps.
My WXP desktop usually has 1 or 2 Windows consoles and 1 or 2 telnet sessions to Linux servers open. But it sounds like telnetting into Fedora will be useless. One has to open an xterm in it's GUI to be able to use accents?
A linux console and a telnet session into a linux box are two very different things. The linux console is the text mode screen you see sitting down at the keyboard (or optionally a serial terminal) of a linux machine. While some people refer to any command-line session as a "console" session, this is inaccurate.
If you are using Windows telnet, you can enter non-ASCII characters as normal: switch to an international keyboard layout and type them as normal.
As an aside, you'd be wise to switch from telnet to ssh though.
It looks like XAML uses its own style system, different and incompatible to CSS.
.NET language can be used for the code bindings, they have to be compiled, unlike XUL/Javascript. This seems to suggest remote, browser-based XAML applications won't be possible, although IE can be used to preview the XAML layout.
The other major difference appears that while any
But it does at least show MS thinks an XML interface description language ala XUL or MacOS X NIB(?) is the direction of the future.
So long as all those Windows licenses are paid for
Thats exactly it. A huge number of Windows licenses are bought and paid for when a computer is purchased. MS has a nice lock on OEMs which forces compliance. If running multiple instances of Windows on a computer takes off, then suddenly MS no longer has any leverage to force users to buy the extra licenses.
Because it is possible to write an insecure program in Linux, Linux is less secure? What a total non-sequitur.
It is trivial to write the above program in any language on any platform; that has absolutely nothing to do with an operating system's security.
What you will notice, though, is that with most Linux/Apache setups, $input will run as user "nobody" or "apache", with very few privileges, so an additional local root exploit would be necessary to do real damage. Unix was designed from the start to allow untrusted users to run programs locally. Its also worth noting that some Windows services can be locked down the same way, but in general, a remote exploit on a Windows box will almost always give you Administrator access.