In many cases this won't help prolong the product
cycles, but can help reduce the repair need. I
don't think the car manufacturers would care anything about putting a few car mechanics out of
business if it would give them the opportunity to
claim their car cost X% less to own a year due to
a lower average maintenance cost.
Of course they are only delaying it. But any delay
means an increased lifetime for the object, and
if the delay is, say 10% of the original lifetime,
and costs less than 10% more, then it's worth it.
He specifically stated that patents were there to
promote the disclosure of what would be otherwise hidden. In the case of pharamceuticals, much research wouldn't be done, and the knowledge wouldn't be available without patent protection.
But do you really think that Amazon wouldn't have
done 1-click shopping if it wasn't patentable? There's no big investments involved. Not much
innovation. And certainly not much implementation
work.
Actually, if watching a few DVDs I own would bring
down the society I'm living in, then the society
really needs to be brought down, because in that
case it's seriously flawed.
The creator only has the rights granted by copyright law. Copyright law restricts those rights
quite extensively, including giving the public
"fair use" rights, which include the rights use
works you buy for practically any purpose in private. This is intended exactly to ensure that
copyright holders can not restrict access to their
works in the way the DVD CCA are trying.
In fact, copyright law's basis is that it should
protect the creators of a works rights only to the extent that it encourages the creation and dissemination of works to the public. In this case
the movie industry is trying to restrict even
paying customers from fair use of the works they've
bought, and that violates the very principles copyright law is built on.
If breaking CSS for fair use purposes violates any
laws, it's the laws that shouldn't be as they are,
and I'd break them whenever I please.
Luckily I don't live in a country that have sillyness like the DMCA (not that the UK doesn't
have more than enough other crappy legislation to
make up for it)
They can make money from that if they have a power plant that can provide the same output with minimal variable cost 24 hours a day. At night they will
likely not use their full capacity. By using the surplus power produced during the night to pump water into a reservoir, heat up a well, or do anything which will allow them to produce more power at daytime, they may be able to improve throughput during the times of day when the power
drain is highest.
It's not about increasing power production, but about efficient short term storage.
It's normal for the "owner" of an acronym or invented name to dictate the official pronounciation. And it's common for abbreviations to get it's own pronounciation, if there are any reasonable alternatives that "sound good". Take TeX, for instance, or SCSI. And in this case, pronouncing it bisco is pretty reasonable.
They were talking about compressing text, as in
human readable, extremely redunant collections
of characters that are typically 8 bit but in
the most western languages use an alphabet that
consume far less.
First of all, an algorithm specialized to say English text, with mostly letters, space, some punctiuation, and digits, it's not a stretch to
be able to get the average case reduced by 25% just
by encoding the letters more efficiently. You could
probably stretch it another 10% or so, by taking
advantage of simple facts like that most capital
letters are at the beginning of a word, and most
words are preceeded by a space, and use mode switching to turn on uppercase for one (most cases), or more letters.
(Note that it's been years since I played around
with text compression, and I'm only describing some
ways of doing it - there are probably lots of much
better ways).
Note that the suggestions above are mostly about
reducing the waste in the encoding of the letters
themselves. They do not deal with the redundancy
inherent in the words themselves. For instance, many 2,3 and 4 letter combinations can be found,
so that certain letters in the combination can be
removed, while you still only have to mark the occasional exception. Vowels are good candidates.
A quick test on a dictionary with about 45000 words
showed that stripping vowels would be possible
without duplicates for about 30000 of them, and
for the words that had wovels stripped, the average
reduction in size was 25%. That translates to an average reduction over the whole text of about 17%
Total over 50% so far.
Further, a lot more words could have wovels stripped for the most often occuring case, but leave them in for the duplicates, yielding an even
larger reduction.
Once you've done all the text specific stuff, you
can top it off with a generic compression algorithm. gzip -9 on the vowel stripped dictionary
I mentioned, compressed it by 65%. 65% further
compression of 50% is 18.5%. Note though that the
gzip compression would not likely be as good on
a generic text as on a sorted word list.
Not quite as good as 12.5%, but close enough to
show that if you spend time on it, 12.5% shouldn't
be that difficult.
Keep in mind that this would be the average case
specifically for English text. It would not apply
to any material that violates one or more of the
assumptions it is based on. In worst case, applying
any of the assumptions above might even make the
result larger.
The lesson? Domain specific compression can yield
very good result with only trivial analysis. But
you won't be able to do lossless compression for
all cases. That's the entire point of domain specific compression: You look at a collection of
data, and find out what is likely and not likely
to occur in the data set, and use that to eliminate
redundancy that a general purpose compression algorithm can not eliminate (or can not eliminate
in all cases)
But no lossless compression algorithm can guarantee
to be able to compress data for all possible inputs.
If you could do that, you'd just apply the compression algorithm to the compressed data, and
repeat that step until you were left with less than
a bit of data... Uhm... Seems a bit difficult?
Like impossible?:-)
Sure, but if it's that cheap, and that small,
you just buy as many of them as you need to get
the access speed where you want it, and do massive mirroring and striping to increase safety and access speeds.
Compared to the cheapest 1TB IDE RAID 5 solutions
I've seen, I could buy 200 of those cards, and mirror and/or stripe across all of them, and get a theoretical transfer rate of 20000 Mb/sec, and
still be left with more storage.
Of course, it still won't replace RAM - you'd likely have way to high latency. And to get a close to linear increase in transfer rate, you'd have to
analyse your data access patterns closely in advance. And you still wouldn't get even close to
the theoretical limit. But even if it meant ending
up on "only" 5000 Mb/sec for a massively parallel
system, instead of 20000 Mb/sec, it would certainly
be worth it.
If I remember correctly (which I'm not sure I do, I may be confusing them with someone else), Cavendish Management Resources is a "venture" company that provide advice and assistance for a
stake in the company. If it's the company I'm thinking about, it does not provide venture capital itself, but does help the companies they work with
help to complete funding rounds besides their other
services.
You forget that there's tons of companies out there that claims to be close to production of similar
devices, some with somewhat less storage space, some with significantly higher storage space. If
this technology works, then it's likely that at least some of the competitors also have technology that works. And this is a field that's ridden with patents, some of which are already expired, or close to expiring - in other words, it's unlikely that any one company will be able to get a strangehold by refusing to license patents, since they'll likely have to get licenses themselves, possibly from the same companies.
It's highly unlikely that they just doubled their
storage. They claim the USENET archive is 1TB, and
given indexing of 1.3 billion webpages, they have
way more than 1TB of webpage data (remember that
efficient indexing eats up lots of space - often
several times the initial document set, especially
when the dataset is huge).
Anyway, storage is cheap. I can buy 1 TB for less than 18.000 USD. A system with enough IO bandwidth
to handle a horde of users querying it, on the other hand, is what will cost them most of the money.
It also hugely increases the number of dockings,
which is inherently risky. And it results in
one more structure to outfit with thrusters,
communication equipment, power supplies, life support systems, etc.
There's a difference. A Spanish speaking user can
learn English. I'm not saying that businesses and
government offices in areas with large Spanish speaking (or whatever other languages) populations
shouldn't consider providing information as well. But when the difficulty is language understanding,
you can get around it by learning the language.
The problem is that most disabled people doesn't have the option of fixing their problem: Most blind people, for example, will stay
blind - for most of them we don't yet have any medical solution.
That is why disabilities has a special status,
compared to many other obstacles people may face
to getting access to government information.
No, I haven't. But I imagine the default version
would be quite bad. However I did switch to the "light" version, and tried that out with Lynx, and
while it wouldn't be ideal, it should be quite possible to deal with.
But I'd salute any blind user of the web anyways - it's not like most web pages are ideal for blind
people. But cumbersome to read is still a lot better than impossible to read.
I did look into emacsspeak a while back, though, because the issue of accessibility is interesting
from a user interface point of view - it's one of
the areas where most user interface innovation
is done, and some of the tools could likely be useful as complementary tools for non-disabled persons as well.
That is ridiculous. I know of several blind people
that use the web frequently. And I'm sure there
are blind users of Slashdot as well. Faced with
a well marked up page where the designer has spent
some time thinking about accessability, modern
screen readers and browser can do a good job.
And one of the express goals of HTML 4 is to separate context from representation much better than with earlier versions of the HTML standard, exactly to make it easier to make the information
available for people with disabilities, and people
using other technology than a standard web browser.
Imagine the mess of having to adjust all the time.
Also, some of the experiments will be more or less continuously ongoing. They basically have two choices.
Rotating
a section, which is expensive, since interconnecting the rotating section safely with
the rest of the station would be a nightmare.
Their other alternative is to rotate the entire
station, and stop it during zero-g experiments. Which is impractical both because of the duration
of experiments, and because of the mess you'd get
each time you started rotation after people had spent a week with g forces, and started leaving things lieing loose, and you suddenly have the station filled with assorted crap floating around.
Uhmm? Linux has had support for more than 4 CPU's
for a while now. There's been reports about people
successfully running Linux of 14 CPU Sparc machines, for instance.
You're wrong. That's how it works if you use Freetype or similar in the client. But XFree86 supports a new extension that allow you to do
server side antialiasing, which means that the
X server either will read straight from disk, and
cache on it's side, or it will transfer glyphs from
a font server, and antialias on it's side.
But caching antialiased glyphs does take more memory, of course.
XFree86 4.0.x supports Freetype for font rendering,
which AFAIK means that you are able to use antialiased Truetype fonts for apps that support
the render extension, and you can also use truetype
fonts (without AA) for legacy apps (under older version of XFree you can do the same by using a
truetype capable fontserver).
Well, it does. I've never seen antialiasing anywhere where the fonts didn't look blurry to
me. That includes Windows, fonts rendered with
T1lib, Freetype, and lots of other cases. That
doesn't mean it's bad for everything - if the fonts
are really crappy to start with it still gets easier to read. But if I have the choice between
a good non-antialiased font and antialiased text
for reading long texts, I'd choose the former.
It still looks cool, though. And I'd likely end up
using it for most stuff:-) And the problem with
fonts becoming blurry goes down at high resolution (but of course, so does the advantages of aa), so
at 1600x1200 at home it should look ok:)
You stupid troll. The patch to QT that is used
for antialiasing under KDE uses the render
extension of XFree86 too, so the antialiasing code
used is the same.
Slashdot Mirror
In many cases this won't help prolong the product cycles, but can help reduce the repair need. I don't think the car manufacturers would care anything about putting a few car mechanics out of business if it would give them the opportunity to claim their car cost X% less to own a year due to a lower average maintenance cost.
Of course they are only delaying it. But any delay means an increased lifetime for the object, and if the delay is, say 10% of the original lifetime, and costs less than 10% more, then it's worth it.
But do you really think that Amazon wouldn't have done 1-click shopping if it wasn't patentable? There's no big investments involved. Not much innovation. And certainly not much implementation work.
You can't patent a logo. A logo can be copyrighted and/or trademarked, but not patented.
Actually, if watching a few DVDs I own would bring down the society I'm living in, then the society really needs to be brought down, because in that case it's seriously flawed.
In fact, copyright law's basis is that it should protect the creators of a works rights only to the extent that it encourages the creation and dissemination of works to the public. In this case the movie industry is trying to restrict even paying customers from fair use of the works they've bought, and that violates the very principles copyright law is built on.
If breaking CSS for fair use purposes violates any laws, it's the laws that shouldn't be as they are, and I'd break them whenever I please.
Luckily I don't live in a country that have sillyness like the DMCA (not that the UK doesn't have more than enough other crappy legislation to make up for it)
I'm not going to pay for an operating system I'll never ever use to be able to play the DVDs that I own on a drive that I own.
It's not about increasing power production, but about efficient short term storage.
It's normal for the "owner" of an acronym or invented name to dictate the official pronounciation. And it's common for abbreviations to get it's own pronounciation, if there are any reasonable alternatives that "sound good". Take TeX, for instance, or SCSI. And in this case, pronouncing it bisco is pretty reasonable.
First of all, an algorithm specialized to say English text, with mostly letters, space, some punctiuation, and digits, it's not a stretch to be able to get the average case reduced by 25% just by encoding the letters more efficiently. You could probably stretch it another 10% or so, by taking advantage of simple facts like that most capital letters are at the beginning of a word, and most words are preceeded by a space, and use mode switching to turn on uppercase for one (most cases), or more letters.
(Note that it's been years since I played around with text compression, and I'm only describing some ways of doing it - there are probably lots of much better ways).
Note that the suggestions above are mostly about reducing the waste in the encoding of the letters themselves. They do not deal with the redundancy inherent in the words themselves. For instance, many 2,3 and 4 letter combinations can be found, so that certain letters in the combination can be removed, while you still only have to mark the occasional exception. Vowels are good candidates.
A quick test on a dictionary with about 45000 words showed that stripping vowels would be possible without duplicates for about 30000 of them, and for the words that had wovels stripped, the average reduction in size was 25%. That translates to an average reduction over the whole text of about 17%
Total over 50% so far.
Further, a lot more words could have wovels stripped for the most often occuring case, but leave them in for the duplicates, yielding an even larger reduction.
Once you've done all the text specific stuff, you can top it off with a generic compression algorithm. gzip -9 on the vowel stripped dictionary I mentioned, compressed it by 65%. 65% further compression of 50% is 18.5%. Note though that the gzip compression would not likely be as good on a generic text as on a sorted word list.
Not quite as good as 12.5%, but close enough to show that if you spend time on it, 12.5% shouldn't be that difficult.
Keep in mind that this would be the average case specifically for English text. It would not apply to any material that violates one or more of the assumptions it is based on. In worst case, applying any of the assumptions above might even make the result larger.
The lesson? Domain specific compression can yield very good result with only trivial analysis. But you won't be able to do lossless compression for all cases. That's the entire point of domain specific compression: You look at a collection of data, and find out what is likely and not likely to occur in the data set, and use that to eliminate redundancy that a general purpose compression algorithm can not eliminate (or can not eliminate in all cases)
But no lossless compression algorithm can guarantee to be able to compress data for all possible inputs.
If you could do that, you'd just apply the compression algorithm to the compressed data, and repeat that step until you were left with less than a bit of data... Uhm... Seems a bit difficult? Like impossible? :-)
Compared to the cheapest 1TB IDE RAID 5 solutions I've seen, I could buy 200 of those cards, and mirror and/or stripe across all of them, and get a theoretical transfer rate of 20000 Mb/sec, and still be left with more storage.
Of course, it still won't replace RAM - you'd likely have way to high latency. And to get a close to linear increase in transfer rate, you'd have to analyse your data access patterns closely in advance. And you still wouldn't get even close to the theoretical limit. But even if it meant ending up on "only" 5000 Mb/sec for a massively parallel system, instead of 20000 Mb/sec, it would certainly be worth it.
If I remember correctly (which I'm not sure I do, I may be confusing them with someone else), Cavendish Management Resources is a "venture" company that provide advice and assistance for a stake in the company. If it's the company I'm thinking about, it does not provide venture capital itself, but does help the companies they work with help to complete funding rounds besides their other services.
You forget that there's tons of companies out there that claims to be close to production of similar devices, some with somewhat less storage space, some with significantly higher storage space. If this technology works, then it's likely that at least some of the competitors also have technology that works. And this is a field that's ridden with patents, some of which are already expired, or close to expiring - in other words, it's unlikely that any one company will be able to get a strangehold by refusing to license patents, since they'll likely have to get licenses themselves, possibly from the same companies.
Anyway, storage is cheap. I can buy 1 TB for less than 18.000 USD. A system with enough IO bandwidth to handle a horde of users querying it, on the other hand, is what will cost them most of the money.
It also hugely increases the number of dockings, which is inherently risky. And it results in one more structure to outfit with thrusters, communication equipment, power supplies, life support systems, etc.
The problem is that most disabled people doesn't have the option of fixing their problem: Most blind people, for example, will stay blind - for most of them we don't yet have any medical solution.
That is why disabilities has a special status, compared to many other obstacles people may face to getting access to government information.
But I'd salute any blind user of the web anyways - it's not like most web pages are ideal for blind people. But cumbersome to read is still a lot better than impossible to read.
I did look into emacsspeak a while back, though, because the issue of accessibility is interesting from a user interface point of view - it's one of the areas where most user interface innovation is done, and some of the tools could likely be useful as complementary tools for non-disabled persons as well.
And one of the express goals of HTML 4 is to separate context from representation much better than with earlier versions of the HTML standard, exactly to make it easier to make the information available for people with disabilities, and people using other technology than a standard web browser.
Rotating a section, which is expensive, since interconnecting the rotating section safely with the rest of the station would be a nightmare.
Their other alternative is to rotate the entire station, and stop it during zero-g experiments. Which is impractical both because of the duration of experiments, and because of the mess you'd get each time you started rotation after people had spent a week with g forces, and started leaving things lieing loose, and you suddenly have the station filled with assorted crap floating around.
You don't "generate gravity". You generate centrifugal forces, which has mostly the same net effect for our purposes.
Uhmm? Linux has had support for more than 4 CPU's for a while now. There's been reports about people successfully running Linux of 14 CPU Sparc machines, for instance.
But caching antialiased glyphs does take more memory, of course.
XFree86 4.0.x supports Freetype for font rendering, which AFAIK means that you are able to use antialiased Truetype fonts for apps that support the render extension, and you can also use truetype fonts (without AA) for legacy apps (under older version of XFree you can do the same by using a truetype capable fontserver).
It still looks cool, though. And I'd likely end up using it for most stuff :-) And the problem with
fonts becoming blurry goes down at high resolution (but of course, so does the advantages of aa), so
at 1600x1200 at home it should look ok :)
You stupid troll. The patch to QT that is used for antialiasing under KDE uses the render extension of XFree86 too, so the antialiasing code used is the same.