Paper problem with relation to currency is only marginal: when you have no cache you can simply write a check.
Not being able to print money can't stave off inflation if velocity of money is high (see http://en.wikipedia.org/wiki/Money_velocity) and vise versa -- increasing money supply when velocity is low will no produce high inflation (present day USA, where the Federal Reserve is "printing money", is one example).
For everybody operating in a corporate environment mail, calendar and address book are delivered by an Exchange server. Thunderbird is good for pop3/imap/ldap which are all open standards but Exchange doesn't talk these protocols.
Enter DavMail -- a proxy that connects to Exchange server on one hand and exports pop3/imap/ldap on the other. I have been successfully using it for the past 3-4 years.
People think Intel's purpose is to impose the x86 instruction set and also that the only culprit that keeps them from making a successful product is the overhead of that very x86 instruction set. I don't believe it.
The interpretation and translation of instructions is some constant number of transistors, the rest of the architecture is moving ahead. There will be a moment when brute force alone, the supremacy of the fabs, will win the race.
Another factor is that when you license ARM you can customize it. You can't license and customize Atom CPUs. Intel is at the moment kept back by a combination of factors
You comments are usually enlightened and I enjoy reading them (you are on my slashdot Firehose). I'd comment on this one because I also dwell on this topic, I strive to identify indicators of what drives the oil prices. One one hand that could be paper speculators on the other could be genuine supply and demand. It is not always clear which is prevailing. Could you please go into more details about your methodology. About the deregulation, do you mean the end of the 90s or some more recent legislature? (It is probably something more recent because at the end of the 90s there was no spike in oil prices).
Reading your post one question popped up: Isn't accepting self-signed certificates useless from security stand point, what will protect users against the risk of man-in-the-middle attacks where adversaries simply supply their own self-signed certificates?
I would add that the negotiated state is cached. And the initial encryption (public keys) is much more expensive that what takes place after that (symmetrical keys).
A problem of HTTPS I noticed is that contents of the page is not cached. If you click on a link and then click Back the page is reloaded. There is no standard for how browsers implement Back button functionality. On Mozilla and Chrome my tests showed significant degrade in speed of Back when the page is in HTTPs mode. Examination of the traffic revealed that when in HTTP no requests go to the server, when in HTTPS everything is requested and loaded fresh.
... we used to have liberty and security, now we have security and empire, but our empire sure doesn't seem to be doing anything for the average citizen.
The Empire gives the ordinary citizen subsidized oil prices. The funding of the army is not explicitly reflected in the gasoline prices. The result is a happy motoring nation. Every ordinary citizen benefits from it.
If a much smaller company was to be at fault it would have never been able to cover the cost of the cleanup. Then an industry funded insurance, managed by the government, will cover these needs.
Cost of this will not be passed to us. We are past the point where the price of the product is cost+fixed_small_profit=price. The price is demand driven, the profits are exorbitant, there is room for insurance there.
Turns out that the government already has a rainy day fund to deal with industry disasters. At present it holds $1.5 billion, it is not adequate but I think this is the way to go. The impact of this accident is going to be felt by the entire industry, it is only logical for funds to be collected from all oil companies to help with recovery efforts.
Newspaper publishers don't stand a chance to charge for their content on the internet, but they can charge for the convenience of it being made available on Kindle.
Now, Amazon is offering them a new sales channel but the pricing is not controlled by the publishers. At least this is the major problem about which the wsj.com complained -- wsj.com: Publishers Nurture Rivals to Kindle
Presently Kindle is not an independent distribution platform. You can't distribute your newspaper on it if you don't sign a deal with Amazon first. While newspapers will be happy to sale content via Kindle, they wouldn't wish to substitute the crummy revenues from internet with the possibility of extortion by Amazon. On top of that there is no room for ads on Kindle, so the content is entirely unsubsidized.
The sections regarding global news, national news, and everything else that competes with the free stuff on internet are free for all readers of wsj.com. The perceived purpose they serve is to eventually bring paying customers.
The financial, business, and market news sections are accessible only to subscribers.
Also, all content is accessible for free if referenced by google search or google news. There is even a toolbar add-on for Firefox which will permit you to read the entire wsj.com by spuffing the reference url for you.
People who are dismissive of the paying model of wsj.com are usually not the target audience of the newspaper. I personally, think it is admirable that they are so confident in their product that they can afford to charge money for accessing it. I love to read newspapers and and I'm willing to pay for it.
Re:Should have used PHP.
on
Twitter On Scala
·
· Score: 3, Interesting
I agree, but wish to add a comment about vertical and horizontal scaling.
Ruby and Python have poor multi-threading. They don't scale well on multi-CPU platforms.
from the interview: Robey Pointer: Green threads don't use the actual operating systemâ(TM)s kernel threads.
So, a Ruby application can't scale well vertically -- one can't just upgrade the machine with more CPUs for example.
At the same time, no language is inherently prohibiting horizontal scaling, if application design provides for it -- adding more machines onto which the application can run in parallel.
Twitter could've been designed to permit horizontal scaling. Regrettably the article didn't say much about this approach. They are improving the vertical scalability of the application by switching to first-class threads (via the JVM), but are they not eventually going to hit the limits for vertical scaling?!
Short term no company can pinpoint how economically beneficial a car could be to its owners by the time actual mass production begins. Long term there is no doubt oil will be a problem, should research wait for oil prices of $200?!
If one considers that lead research time takes 4 years and oil prices fluctuated between 40 to 160 and back to 40 in the span of 2 years, when should a company seriously undertake the task of designing a vehicle like the Vault?! Bold decisions like the one to design the electrical car should be commended and possibly financially (tax credits, direct investment) encouraged by the government.
System could be set up which is not part from the government. It has to have element of solidarity, this doesn't inherently come from it being the government: sicker people are subsidized by healthier individuals. Every body pays into this system and it can be separate from government taxes. This could be a solid finance base on top of which one can impose voluntary insurance for extra benefits -- getting better room, color TV, etc. while in hospital.
If it is separate is could be better managed. And there could be more focused pressure on eliminating waste and demanding better prices from hospitals and other providers. I feel it will be less so if money come from the general pool of collected taxes. It will also be more cleanly delineated on your pay check as a separate item.
Just a week ago BusinessWeek had a piece about health care insurance companies buying your prescription drug history onto which they base your insurance premium.
Health care probably needs more an element of solidarity. Insurance is a business and as such it is legitimate for them to aspire for higher profits. Cynically, it is also legitimate for an insurance company to deny services to higher risk individuals. It is legitimate for a business but it points to deep deficiencies in how health care finances are set up in US.
In contrast, Germany's system (and probably others in Europe) has an element of solidarity. Healthier people subsidize sicker people. American system is an insurance, set up for calamity but actually used as pre-paid service.
To me de Icaza was always the leading technologist of GNOME. Sadly he went into a direction that contributed to the loss of focus of what GNOME is. With indemnification or not, many of the main contributors to GNOME will not include anything that uses Mono.
Sun for certain will not work with a direct competitor to Java. Red Hat will rightfully avoid including something that requires them to go in bed with Microsoft over patents.
Linux kernel development shows that big free software projects need both enthusiast but also corporate contributors. So GNOME, not unlike the kernel, garnered support by companies like Sun, but also countless small guy contributors. With Mono de Icaza put powerful centrifugal forces that work against GNOME.
Very pertinent to this discussion is a piece from the financial newspaper Barron's which was posted yesterday. It is a positive review of RedHat's business model as one being based on subscriptions and not one time sales. Here is an excerpt from the article:
"But I think the best opportunity is to target companies offering software as a service."
Worldwide software sales should grow 8% this year, which, while down from 8.7% last year, nonetheless proves that "there is clear evidence of pent-up demand for new software technology," says Joanne Correia, a software analyst with Gartner Inc. in Stamford, Conn.
But software spending increasingly goes to the top four vendors -- IBM, Microsoft, SAP and Oracle -- whose combined share of global software spending jumped from 33.5% in 2000 to 36.8% last year, estimates Charles Di Bona with Sanford C. Bernstein & Co. in New York.
So to get a leg up, small young vendors are changing the rules of engagement. They are eschewing the multimillion-dollar one-time contracts for software and instead letting corporate buyers pay for product updates and support on a year-by-year basis.
"We're seeing a shift in the economic balance," in software sales, says Correia's colleague, Simon Hayward. "From this up-front cost of software to an annuity model, with money shifting to firms that are service providers."
Of Red Hat's $278 million in sales last year, 82% was from subscriptions, which the company realizes over the life of a contract of one to three years. Oracle still gets over a third of its sales the old way.
Red Hat's sales should rise 35% this year to $375 million, far above the 15% rate expected for Oracle, according to estimates from Goldman Sachs analyst Rick Sherlund.
Subscriptions should make Red Hat's sales -- and its customers' expenses -- more predictable, which is good.
"You're able to match your revenue model to the way that you provide that product to your customer," notes Ursillo.
"If you are constantly providing them with value as opposed to a one-shot deal, then you can charge them on a regular basis," he says.
What's more, by acquiring subscribers, rather than one-time buyers, Red Hat can milk its customer base by offering more and more new programs.
In addition to the Linux operating system, Red Hat now provides software to let companies take transactions over the Internet.
"They are in the first inning of a very big ballgame," says Steven Ashley, an analyst with Robert W. Baird & Co. in Milwaukee.
I doubt anyone cares about that right now. Do you have any reference backing this up at all? Most low end printers even render a single page multiple times because they lack the buffer memory to store the whole page, and the processors are quite slow compared to desktop CPUs (think tens of MHz). A high end printer is one that can store the whole page, and has a decent processor. I don't think they're at the point where they need SMT or multicore processors.
I admit that by saying "high-end printer" I failed to convey precisely what printer segment I'm talking about. One good example of the category is Xerox Phaser 7750 Color Printer, model 7750/DXF. Currently offered at just below $10'000.
First it mentiones that one of the supported print languages is PDF v1.4. You will be able to see that it has up to 1GB of memory and the CPU is most likely not below 500MHz. I'm confident that it carries a hard drive, again PDF can't be processed (linearized PDF permits you to only print the first page independently) until they are received in its entirety and a large file will require commensurate storage.
I believe that if Xerox invests time and money to build this product, there would be people who care to buy it.
Interpreting is normally the bottleneck. Postscript is extremely easy to parse (by design).
Structured Postscript allows you to render different pages in parallel. I don't know why you'd need to go much beyond that anytime soon, at least for printing purposes.
Imagine that you have to design a machine that renders rasters with a rate of 250 to 300 pages per minute. You will most likely demand a dual CPU board, plenty of memory and a hard drive. Efficient use of multiple CPUs would require parallel rendering. Postscript and PDF are not complicated languages but you have to balance the speed of interpreting with the process of feeding two hungry render beasts and keep CPU usage high. There will be a point where single interpreter will be unable to feed increasing number of parallel renders.
The evolition of printers is such that it delivers faster and faster engines, at one point a single threaded language interpreter will just not cut it. PDF is almost there, just it requires access to the end of the file before parallel interpreting can begin. Technically, XPS is a step forward, although probably for most of the people (home and small office users) it is irrelevant.
There are probably quite a few high-end printers that can print PDF directly, no Acrobat Reader necessary. In the world of this industry the best achievers aspire to make the page rendering as multi-threaded as possible. Internally this means that the printer has two or more raster generators that work in parallel.
Data fed to the printer is not a random-acess binary but is in a serial text format. What this means is that while rasters can be generated in parallel, most likely the parsing of the printing language (PostScript for example) can only go serially, hence a bottleneck.
The next step in printing languages will be to have the pages described in a way that will permit parallel interpreting.
One big disadvantage of PDF is that one has to receive the entire file before printing begins -- the index of the pages is at the end of the file. In contrast XPS is designed to explicitely help printer interprers begin to work immediately after page-end marker is received. All data referenced by this page has already been send to the device, intepreting of this page can start immediately and go independently and in parallel with another instance of the interpreter. In this regard XPS is better.
Locating its center of gravity in Canada is something of which OpenBSD takes great pride. This is not unreasanoble in light of the adverse legal envyronment and export limitations that security research faces in US.
Speaking of money, charitable donations, US is probably the best place to try to sell your cause. I believe that part of the work on OpenBSD could be supported by a non-profit organization registered in the US. Foundations permit donors to deduct the amount of the grant from their taxes, a benefit which, presently, OpenBSD denies to its benefactors.
I believe that Symantec's C++ compiler is based on the one developed by Zortech (known to people who programmed C in the age of DOS). Presently this is Digital Mars and one of their FAQ pages talks briefly about the compiler's heritage.
I once read in Dr. Dobb's Journal mentioning about Walter Bright acquiring back the rights of the Zortech's compiler after Symantec lost interest in its development.
There are performance gains as well. In the current libc malloc (GNU libc, the one we use on linux and the old OpenBSD) the method of asking the kernel for memory is brk(). This means that the application's heap is one contiguous entity. The free heap memory is a linked list and it occupies virtual memory and potentially some swap space on disk.
The fact that the unused heap is swapped to disk is usually a false argument that brk() works -- you free heap memory and later on when the OS swaps this out you free the physical memory also. One additional problem with this scheme is that the free heap is a linked list, sometimes walking this list requires bringing the free heap memory back from disk!
The changes in the OpenBSD were in the implementation of the libc, freedom denied to the Linux developers -- Linux is only the kernel. BSDs are entire OS packages, changes in the kernel are accompanied by the necessary changes in the libc, this is not the independent GNU libc.
The forementioned improvement in malloc(), which was not detailed in the post, is based on a departure from the old fashioned heap paradigms. No use of brk(), but direct mmap/unmap(), thus reducing the size of the virtual memory. Second, the free heap is no longer a linked list but is kept lumped together in one single place, which brings two benefits. No swapping in of free heap from disk and no danger of unwanted user stepped-over writes that might destroy the list.
Slashdot Mirror
Paper problem with relation to currency is only marginal: when you have no cache you can simply write a check.
Not being able to print money can't stave off inflation if velocity of money is high (see http://en.wikipedia.org/wiki/Money_velocity) and vise versa -- increasing money supply when velocity is low will no produce high inflation (present day USA, where the Federal Reserve is "printing money", is one example).
For everybody operating in a corporate environment mail, calendar and address book are delivered by an Exchange server. Thunderbird is good for pop3/imap/ldap which are all open standards but Exchange doesn't talk these protocols.
Enter DavMail -- a proxy that connects to Exchange server on one hand and exports pop3/imap/ldap on the other. I have been successfully using it for the past 3-4 years.
(bashrc.sourceforge.net -- configuration tricks for bashrc)
I think it was sold because of pride. How could a CPU giant license designs from puny ARM from England?!
-- http://bashrc.sourceforge.net
People think Intel's purpose is to impose the x86 instruction set and also that the only culprit that keeps them from making a successful product is the overhead of that very x86 instruction set. I don't believe it.
The interpretation and translation of instructions is some constant number of transistors, the rest of the architecture is moving ahead. There will be a moment when brute force alone, the supremacy of the fabs, will win the race.
Another factor is that when you license ARM you can customize it. You can't license and customize Atom CPUs. Intel is at the moment kept back by a combination of factors
-- http://bashrc.sourceforge.net
You comments are usually enlightened and I enjoy reading them (you are on my slashdot Firehose). I'd comment on this one because I also dwell on this topic, I strive to identify indicators of what drives the oil prices. One one hand that could be paper speculators on the other could be genuine supply and demand. It is not always clear which is prevailing. Could you please go into more details about your methodology. About the deregulation, do you mean the end of the 90s or some more recent legislature? (It is probably something more recent because at the end of the 90s there was no spike in oil prices).
Reading your post one question popped up: Isn't accepting self-signed certificates useless from security stand point, what will protect users against the risk of man-in-the-middle attacks where adversaries simply supply their own self-signed certificates?
I would add that the negotiated state is cached. And the initial encryption (public keys) is much more expensive that what takes place after that (symmetrical keys).
A problem of HTTPS I noticed is that contents of the page is not cached. If you click on a link and then click Back the page is reloaded. There is no standard for how browsers implement Back button functionality. On Mozilla and Chrome my tests showed significant degrade in speed of Back when the page is in HTTPs mode. Examination of the traffic revealed that when in HTTP no requests go to the server, when in HTTPS everything is requested and loaded fresh.
... we used to have liberty and security, now we have security and empire, but our empire sure doesn't seem to be doing anything for the average citizen.
The Empire gives the ordinary citizen subsidized oil prices. The funding of the army is not explicitly reflected in the gasoline prices. The result is a happy motoring nation. Every ordinary citizen benefits from it.
Yes. This very low cap of the liability is a prime example of successful lobbying in DC.
If a much smaller company was to be at fault it would have never been able to cover the cost of the cleanup. Then an industry funded insurance, managed by the government, will cover these needs.
Cost of this will not be passed to us. We are past the point where the price of the product is cost+fixed_small_profit=price. The price is demand driven, the profits are exorbitant, there is room for insurance there.
Turns out that the government already has a rainy day fund to deal with industry disasters. At present it holds $1.5 billion, it is not adequate but I think this is the way to go. The impact of this accident is going to be felt by the entire industry, it is only logical for funds to be collected from all oil companies to help with recovery efforts.
Tax on Oil May Help Pay for Cleanup
Curiously BP is not carrying insurance, it is having self-insurance -- they apportion an amount of almost a billion a year into a fund on the island of Gernesey (the offshore UK tax haven).
Insurance rates will go up
Newspaper publishers don't stand a chance to charge for their content on the internet, but they can charge for the convenience of it being made available on Kindle.
Now, Amazon is offering them a new sales channel but the pricing is not controlled by the publishers. At least this is the major problem about which the wsj.com complained -- wsj.com: Publishers Nurture Rivals to Kindle
Presently Kindle is not an independent distribution platform. You can't distribute your newspaper on it if you don't sign a deal with Amazon first. While newspapers will be happy to sale content via Kindle, they wouldn't wish to substitute the crummy revenues from internet with the possibility of extortion by Amazon. On top of that there is no room for ads on Kindle, so the content is entirely unsubsidized.
The sections regarding global news, national news, and everything else that competes with the free stuff on internet are free for all readers of wsj.com. The perceived purpose they serve is to eventually bring paying customers.
The financial, business, and market news sections are accessible only to subscribers.
Also, all content is accessible for free if referenced by google search or google news. There is even a toolbar add-on for Firefox which will permit you to read the entire wsj.com by spuffing the reference url for you.
People who are dismissive of the paying model of wsj.com are usually not the target audience of the newspaper. I personally, think it is admirable that they are so confident in their product that they can afford to charge money for accessing it. I love to read newspapers and and I'm willing to pay for it.
I agree, but wish to add a comment about vertical and horizontal scaling.
Ruby and Python have poor multi-threading. They don't scale well on multi-CPU platforms.
from the interview:
Robey Pointer: Green threads don't use the actual operating systemâ(TM)s kernel threads.
So, a Ruby application can't scale well vertically -- one can't just upgrade the machine with more CPUs for example.
At the same time, no language is inherently prohibiting horizontal scaling, if application design provides for it -- adding more machines onto which the application can run in parallel.
Twitter could've been designed to permit horizontal scaling. Regrettably the article didn't say much about this approach. They are improving the vertical scalability of the application by switching to first-class threads (via the JVM), but are they not eventually going to hit the limits for vertical scaling?!
I agree.
Short term no company can pinpoint how economically beneficial a car could be to its owners by the time actual mass production begins. Long term there is no doubt oil will be a problem, should research wait for oil prices of $200?!
If one considers that lead research time takes 4 years and oil prices fluctuated between 40 to 160 and back to 40 in the span of 2 years, when should a company seriously undertake the task of designing a vehicle like the Vault?! Bold decisions like the one to design the electrical car should be commended and possibly financially (tax credits, direct investment) encouraged by the government.
System could be set up which is not part from the government. It has to have element of solidarity, this doesn't inherently come from it being the government: sicker people are subsidized by healthier individuals. Every body pays into this system and it can be separate from government taxes. This could be a solid finance base on top of which one can impose voluntary insurance for extra benefits -- getting better room, color TV, etc. while in hospital.
If it is separate is could be better managed. And there could be more focused pressure on eliminating waste and demanding better prices from hospitals and other providers. I feel it will be less so if money come from the general pool of collected taxes. It will also be more cleanly delineated on your pay check as a separate item.
Just a week ago BusinessWeek had a piece about health care insurance companies buying your prescription drug history onto which they base your insurance premium.
http://www.businessweek.com/magazine/content/08_31/b4094000643943.htm
Health care probably needs more an element of solidarity. Insurance is a business and as such it is legitimate for them to aspire for higher profits. Cynically, it is also legitimate for an insurance company to deny services to higher risk individuals. It is legitimate for a business but it points to deep deficiencies in how health care finances are set up in US.
In contrast, Germany's system (and probably others in Europe) has an element of solidarity. Healthier people subsidize sicker people. American system is an insurance, set up for calamity but actually used as pre-paid service.
To me de Icaza was always the leading technologist of GNOME. Sadly he went into a direction that contributed to the loss of focus of what GNOME is. With indemnification or not, many of the main contributors to GNOME will not include anything that uses Mono.
.02$
Sun for certain will not work with a direct competitor to Java. Red Hat will rightfully avoid including something that requires them to go in bed with Microsoft over patents.
Linux kernel development shows that big free software projects need both enthusiast but also corporate contributors. So GNOME, not unlike the kernel, garnered support by companies like Sun, but also countless small guy contributors. With Mono de Icaza put powerful centrifugal forces that work against GNOME.
just my
---
I admit that by saying "high-end printer" I failed to convey precisely what printer segment I'm talking about. One good example of the category is Xerox Phaser 7750 Color Printer, model 7750/DXF. Currently offered at just below $10'000.
To check out the spec please go to: http://tinyurl.com/muhqf [http://www.direct.xerox.com]
First it mentiones that one of the supported print languages is PDF v1.4. You will be able to see that it has up to 1GB of memory and the CPU is most likely not below 500MHz. I'm confident that it carries a hard drive, again PDF can't be processed (linearized PDF permits you to only print the first page independently) until they are received in its entirety and a large file will require commensurate storage.
I believe that if Xerox invests time and money to build this product, there would be people who care to buy it.
Interpreting is normally the bottleneck. Postscript is extremely easy to parse (by design).
Structured Postscript allows you to render different pages in parallel. I don't know why you'd need to go much beyond that anytime soon, at least for printing purposes.
Imagine that you have to design a machine that renders rasters with a rate of 250 to 300 pages per minute. You will most likely demand a dual CPU board, plenty of memory and a hard drive. Efficient use of multiple CPUs would require parallel rendering. Postscript and PDF are not complicated languages but you have to balance the speed of interpreting with the process of feeding two hungry render beasts and keep CPU usage high. There will be a point where single interpreter will be unable to feed increasing number of parallel renders.
The evolition of printers is such that it delivers faster and faster engines, at one point a single threaded language interpreter will just not cut it. PDF is almost there, just it requires access to the end of the file before parallel interpreting can begin. Technically, XPS is a step forward, although probably for most of the people (home and small office users) it is irrelevant.
There are probably quite a few high-end printers that can print PDF directly, no Acrobat Reader necessary. In the world of this industry the best achievers aspire to make the page rendering as multi-threaded as possible. Internally this means that the printer has two or more raster generators that work in parallel.
Data fed to the printer is not a random-acess binary but is in a serial text format. What this means is that while rasters can be generated in parallel, most likely the parsing of the printing language (PostScript for example) can only go serially, hence a bottleneck.
The next step in printing languages will be to have the pages described in a way that will permit parallel interpreting.
One big disadvantage of PDF is that one has to receive the entire file before printing begins -- the index of the pages is at the end of the file. In contrast XPS is designed to explicitely help printer interprers begin to work immediately after page-end marker is received. All data referenced by this page has already been send to the device, intepreting of this page can start immediately and go independently and in parallel with another instance of the interpreter. In this regard XPS is better.
Locating its center of gravity in Canada is something of which OpenBSD takes great pride. This is not unreasanoble in light of the adverse legal envyronment and export limitations that security research faces in US.
Speaking of money, charitable donations, US is probably the best place to try to sell your cause. I believe that part of the work on OpenBSD could be supported by a non-profit organization registered in the US. Foundations permit donors to deduct the amount of the grant from their taxes, a benefit which, presently, OpenBSD denies to its benefactors.
Brother, improving your security is as easy as ordering a CD: http://www.openbsd.org/orders.html
The CDs that OpenBSD project sells is their main source of revenue and support.
I believe that Symantec's C++ compiler is based on the one developed by Zortech (known to people who programmed C in the age of DOS). Presently this is Digital Mars and one of their FAQ pages talks briefly about the compiler's heritage.
I once read in Dr. Dobb's Journal mentioning about Walter Bright acquiring back the rights of the Zortech's compiler after Symantec lost interest in its development.
The fact that the unused heap is swapped to disk is usually a false argument that brk() works -- you free heap memory and later on when the OS swaps this out you free the physical memory also. One additional problem with this scheme is that the free heap is a linked list, sometimes walking this list requires bringing the free heap memory back from disk!
The changes in the OpenBSD were in the implementation of the libc, freedom denied to the Linux developers -- Linux is only the kernel. BSDs are entire OS packages, changes in the kernel are accompanied by the necessary changes in the libc, this is not the independent GNU libc.
The forementioned improvement in malloc(), which was not detailed in the post, is based on a departure from the old fashioned heap paradigms. No use of brk(), but direct mmap/unmap(), thus reducing the size of the virtual memory. Second, the free heap is no longer a linked list but is kept lumped together in one single place, which brings two benefits. No swapping in of free heap from disk and no danger of unwanted user stepped-over writes that might destroy the list.