Actually, they will use the opportunity to make 1000 clones of you
for their clone army but forget that these people have jury duty, and
so they will all show up as jurors claiming they have never met you
before. You will thus be acquitted but will be mistaken for someone
else because your DNA matches, so that you are then sent to
Afghanistan, where you will be placed on landmine removal duty. In
the meantime, the soldier-clone you displaced is arrested
trying to board a military transport and, obviously an impostor, is
sent to jail, where the process starts all over again.
As millions of copies of you begin to spread all over the Earth,
nobody is the wiser when you manage to elect yourself as president.
With majorities in all political bodies, you and your clones pass a
law banning the forcible collection of DNA.
Ok, your response is about as full of information as the crap from
this article.
I find your lack of faith disturbing. Are you *gasp* criticizing
the unassailable accuracy of the official computer press?
(Shhh... speak only in whispers, comrade, for I hear the sound of boots
in the distance...)
Take for example your 128mb example.
That was originally your example, not mine.
Notice the reviews says the 'TOP OF THE LINE'. You somehow even miss
that.
You miss the original point. Top of the line or no top of the line
-- having a video card under load all the time is going to draw a
$#!%-load of extra power off the grid when you multiply that against
millions of computers. In many cases, it will double the
average power draw of each. That's not particularly helpful now with
the price of fuel going up. Or becoming scarce. Whether the number
of computers that can have this running is 50 million (fast ones) or
200 million (slow ones), you can debate the specific tiers all you
want but the original point of profligacy still applies.
Before this change, only a minority of the world's people would be
putting their video cards at full load at any given time. Now it will
be practically every computer in every office in the world. And, as
one of the articles points out, the productivity returns of 3D office
apps are not only diminishing, they are arguably nonexistent. There
is no real gain for this energy waste, so why keep fooling people?
They will be unexpectedly surprised when they get their energy bill,
or angry if it causes a blackout, or worse if heating oil runs out in
the winter because some TOP OF THE LINE people wanted to see 3D flying
monkeys coming out of their Orifice application.
For the TOP OF THE LINE Glass/AERO Blurring and Transparent effects,
yes it does take a video card made in the last 4 years with 64mb of
RAM.
You're still saying 64M of RAM on the video card, while Tom's
Hardware says you will be compelled to get at least
256M on the video card. That's quite a margin. You two disagree by
over 4x. Why should I believe you instead of Tom's? And why would PC
World not report the correct figure that MSFT themselves gave them?
And yes the computer only had 128Mb of SYSTEM RAM, and for video
it has 2Mb
A virus scanner by itself will use up that much. You
obviously have no idea what people will use it for in the real world.
I'm sorry the media misleads you, but maybe trying something for
yourself would be better in the long run instead of just believing the
reviews or the commercials the rest of your life.
Or, maybe $200 later a lot of us would only find out that your
claims are false because all of the traffic to the system bus is being
tied up by the video card in order to do those fast-looking 3D
operations. I predict that on an AGP motherboard, simultaneous disk
I/O will turn to molasses because the bus will be saturated by the
video traffic. That is the true system bottleneck being slowed there.
It will be slower than the previous operating systems for real work.
Some improvement! And when WinFS comes along, the CPU or chipset will
have to constantly encrypt and decrypt every damned thing on the disk,
loading new machines even more and slowing older ones into doorstop
status.
This will force people to upgrade their computers and you know it.
And it will get hot in those offices. Or should I call them
sweatshops by now, because you'll have CPU + chipset + video card all
churning away under full load, drawing excess power and generating
heat. Lots of heat. It will be like HELL:)
we even force our testers to use these systems, and run everything
from CorelDraw to Microsoft Office.
Sure, but do you use whips and pitchforks on them?
You forget Apple, they reinvented themselves more than once AND always have managed to be the frontrunner
of computer innovation...
While I agree with you that Apple has done it more often than Winblows, you also seem to be ignoring a little something called the Amiga, back when most operating systems were still single-tasking and video editing required a supercomputer. I'm curious
what you thought of that, or if you had ever heard of such a thing. Was it really innovative, or are the various versions of history being proposed here all being edited for the general audience?
Well, but suppose 100 years from now we learn how to capture a small planet and place it in earth orbit. Does we stop calling it a planet at that point?
Talking about TC would be a largely theoretical exercise at the
moment.
Google TPCA, TCG, TPM. Quite real and already here, unfortunately. The operating systems to use TC features are almost here. Anonymous bloggers in repressive regimes would need to begin worrying about it already, so they can make the right purchases and avoid the wrong ones. Once the full system is in place, it will be too late and it will seem strange to be seen buying old hardware.
Computers with a TC chip are rare,
It's theTPM chip that implements the TC spec. Almost all x86 motherboards for sale today have taken the TPM
functionality and integrated it into the chipset or CPU so it is no longer a separate chip. Read about your
favorite new motherboard chipset and (if the PR people haven't hidden it by now) then compare older chipsets with
the newer ones -- you will see the newer ones all claim to have a
"security" feature of some kind. Try to find any details of the feature. Hint: they are no longer bragging about it like they used to.
and are there any applications at all that use TC to generate such a
unique ID?
The unique ID is in the TPM itself. It is never released to you,
the supposed user, despite the fact that you supposedly own the
computer. If you want to read about this in detail, you will need to read a lot and keep an open mind because there is a lot of PR in the way of the facts.
Posted by michael on Sat Jan 24, '04 05:03 AM from the uh-oh dept.
mmurphy000 writes "News(.com)+ reports that Microsoft has filed for
patents in multiple jurisdictions to control the way other
applications use Office's new XML-based file formats. Musings from
pundits suggest that OpenOffice.org and other applications might be
blocked from interoperating with Office. This, of course on the heels
of today's article on Bruce Perens' concerns over patents."
It seems the "open" file format XML is a busy place for them to unload their proprietary patents. If someone built a freeway, I'm sure these jokers could figure out a way to place their own toll booth in the middle of it.
First, it looks like the moderators who said I was offtopic in the
GP haven't taken the trouble to investigate Trusted Computing
thoroughly enough. It is as relevant as anything else on here.
Now I will have to explain myself in more detail. Those who don't believe that your computer will gain the ability to betray you should perhaps begin by reading
this, where it said that...
Transmeta's security technology was not designed to specifically
target DRM technologies. DRM applications can certainly utilize our
secure, hidden storage facilities to protect the digital certificates
that they use, but we also see broader application into embedded
markets, especially as we work towards extending our secure storage
mechanisms beyond mere data to provide protection of entire algorithms
and other intellectual property that our customers may wish to hide
from the user-visible x86 space," the spokesman said.
My emphasis. In short, applications will be able to hide data from
users. Since then, there seems to have been a tendency to try to
occlude the natural meaning of "user" so that this capability is not obvious,
but in 2003 nobody understood TC well enough to worry about the controversy, so they had it in the correct context. Amazing, huh? Now, back to what I was going to post...
If TC hasn't been taken into account by the brochure, I worry they
may ignore some of the finer implications. To begin with, applications on
your own computer (not necessarily the connecting computer) will be
able to store information about what you are doing and when and to
"protect" it, without giving you the ability to look at that
information yourself or to even know where it is stored. If the
reporter is ever caught, the reporter may not know that there is
incriminating information hidden on her own computer. So, it is no
longer enough to just destructively delete a browser cache or
something and be reasonably certain nobody can prove you authored a
message. And, have you checked what data spyware may be sending out
of your computer -- now with your unique, attestable identity attached
to it?
So, if the brochure doesn't address that, it's only good for a
short time.
The AC seems to be saying that the source of a comment can be
hidden by bouncing it around to different places, so that the
destination site cannot tell where it came from, and so that the
service at the source cannot tell it is a disparaging comment until it
is already posted. Well, that assumes that all of the intervening
sites aren't cooperating, and they may have to cooperate in order to
remain in business in a given country. Since the identities of the
people sending traffic to cooperating sites will be known up to the
point where the traffic reaches a non-cooperating site, anyone
constantly sending traffic to a non-cooperating site will be
investigated more closely. If the result of the investigation narrows
it down to a few people, then all of their computers can be searched
to reveal the reporter.
So, it may not be impossible to remain anonymous but it becomes risky and harder, and
with technologies that are meandering this way, becomes near impossible.
Eventually the only solution may be to spread a rumor to a bunch of
people you dislike and hope they type it for you:)
tropical storm Pi: Every time I tell the residents here that the storm
is coming I am roundly criticized. I tried to convince them to leave
but they are diametrically opposed.
Hurricane Lambda: Nobody could'a predicted that we would see a
recursion of storm activity so soon after tropical storm Kappa headed
back out into the gulf. It just seems to keep returning. Everywhere
people are asking "when will we have closure?" but there is no result,
just a bunch of empty arguments. As for me, I'm going to pass on
those.
Are you saying that there are no fatal flaws in either of the parsers you mention and that you heartily recommend that very very large XML documents be used liberally and frequently with both by large installations, because it is not required to keep the documents fully in memory with either?
Or, is the parent unfamiliar because "everyone knows" they should not be using a parser with a design flaw that can be exploited simply by introducing a huge document? Then why is the flawed parser still in the standard if "everyone knows" it is flawed? Is it because "everyone agrees" the other one has its own flaws, so as to try to avoid that by default?
If neither is a good solution, do you know of several other parsers or alternate APIs that should be added to the standard to help make sure that one of them will be of use to everyone in all situations? Or, should customization like that be discouraged so that the number of parsers and APIs is kept only to those that everyone knows about?
Incidentally, thanks for not being all "stfu dumbass" like too many
posts on slashdot tend to be.
Thanks for noticing. This whole idea of what causes people to come
to heated disagreements is an interesting science, in and of itself.
If you see me casting insults, maybe it is just because I am
researching the state of the art:)
... the original argument that XML is bad for configuration files...that is
demonstrable horse shit.
On the other hand, the argument that it's infinitely better for
that purpose hasn't been proven to everyone conclusively. You may
know of a link that makes a better case, but thus far, I have only
seen a lot of hand waving, like: "Oh, it can be made to boot faster on
hardware that is lightning fast anyway and coincidentally has had
other booting impediments systematically removed and deserialized."
That's like saying we added (3 + e^1000) and got a really big number,
therefore the 3 deserves the credit for the bigness in the result
because, not only did it come first but it is the topic of the
article. So you could argue on and on about the quality of the
horseshit on this side, or the merits of the horseshit on that side,
but the real difference is that one of them is bursting out at high
pressure, and you can instantly spot which one because it's the one
with the marketing push and the buzz surrounding it.
I recognize XML may make sense for other folks. Companies like
Apple can sign cross licensing deals with XML patent holders like MSFT
to shield themselves from negative IP impacts in the future, but OSS
can't do that because it's not a patent-owning corporation, and it is
already giving its stuff away. Since MSFT has marked Linux as its
enemy, a push for ubiquitous XML on Linux or other sweeping ideas that
appear to come out of nowhere are best taken with a grain of salt.
The source of the push may not necessarily be founded on good
engineering principles. So, if the engineering impacts aren't
strongly positive, people can afford to watch from the sidelines.
Is the XML standard likely to stabilize any time soon? There is the
hidden danger that, once in place at the system choke points, you are
basically allowing a standards body with no understanding of OS
internals to indirectly design the future of posix operating systems.
"We decree your library should add 15 more parsers and store them
unswappably in RAM." "We decree that you use an 32 byte per character
representation of text." "We decree that you add XML 'accelerating'
hardware to your system." (In effect:) "We decree you follow the pace
of our planned obsolescence cycle." All that, and eventually someone
shouts "software patent violation" and pulls the rug out from under
you. (Not that it will all come true but that it's wise to ask "who
benefits" and use the "follow the money" maxim.)
If you want a well-defined, flexible and
verifiable config format that allows easy merging and modification of
content, you've just reimplemented XML anyway.
XML is hierarchical. Structured hierarchies, while simplifying and
appropriate in many cases fail at both extremes: the case of a trivial
app in its formative stages and the case of a super-complex app. A
trivial app's designer will balk at reading API documentation just for
a one-page daemon's configuration, when a text file with a port number
in it takes 5 seconds. The super-complex app designer may not mind reading
several APIs but will eventually need a configuration that is
executable in its own right -- a scripting language. So, if you are
going to make a substantial change in the infrastructure of an OS, why
not plan for the long term? If XML will be transformed into a
scripting language, how readable will it ultimately be?
he turns into a simpering pussy that
claims everything is "too hard to read" and "too bloated". Then he
goes on to
I haven't had time to read the RSF brochure, but does it explain what to do if you have a TC setup (a computer that can attest to a unique identity like CPUID but more unique than that) so that all messages can be traced back to the computer that sent it?
It sounds like their suggestions would only be useful for a short while, until all computing equipment is replaced with TCG-compliant stuff, (or even before, by using an older case to contain a new computer). If anonymous bloggers are not careful, someday they will be nabbed.
I wonder if this will usher in a new era of strict dictatorships and unparalled oppression? We may never know, since no one may be able to report about it:)
No, IMHO what we have is heaven compared to a situation where we
have the additional headache of switching out glibc as well. You can
change the other libs out without a reboot and without impacting
non-XML software, which is about 99.9999% of it. Why should unrelated
software and services be interrupted just because someone decided on
this standard without discussion of other, possibly better ones that
may come along? We don't need to make this like Winblows where every
install of an IM client requires a reboot. We should be moving
away from that approach. It is inconvenient to desktop users
as well as the server people. Even they have admitted by now that
they were wrong on this one...
so that those 'several libraries' (and the kernel) can also use it,
But... somebody has to rewrite and test all of those libraries to
make them all consistent with each version of glibc that is released.
If they are consistent with one, they will almost certainly be
inconsistent with the other. So, depending on what is added, you
could create more of a 'dependency hell' scenario than where you
started. Dependency hells are best resolved though open communication
of the library architects and developers. Glibc is not a magic bullet
that solves all dependency problems, it will require even more
consensus to achieve that goal.
glibc contains code for reading fstab, so to move fstab into xml glibc
would need to include an xml parser
So then you would need both an fstab and an fstab.xml, to make sure
that your machine can boot after the upgrade, and so that it can still
boot if you need to downgrade (because maybe the new glibc broke
something unexpected, so you keep it around as a backup...) Then the
glibc will have to have the tiny fstab parser plus the XML
version N parser (more complex and 1000 times bigger?) in order to be
gracefully backwards compatible when booting from a filesystem where
someone left out the fstab.xml, so as not to be locked out.
So, glibc will not really be reduced or simplified by this change,
it will only grow, duplicate effort and become harder to maintain.
Then, of course, you may need to downgrade to the old glibc a long
time later and forget that you need fstab for that version and maybe
only be stuck with fstab.xml by that time, so that your system will
not boot, and you will have to do a bunch of hunting around for what
is supposed to be in XML and what is not and then a bunch of
reconfiguring work in addition to the library changes before you can
boot. Finally, I suppose some people will end up with both fstab.xml
and fstab side by side and will not know which of the two is the
effective one at any one time, leading to unpredicable behavior. In
some cases people will end up needing to hire a consultant to figure
out what's going on with their systems.
I have to recompile my system whenever the base library changes
significantly
That's the point. You want your base library to change as
infrequently as possible. If you don't change the base library, you
don't have to be recompiling everything all of the time. With a
separate XML lib, you only have to recompile the apps that depend on
that lib. If you already have dependency problems with those, those
should be completely resolved and the differences hashed out between
the contenders before even beginning to discuss inclusion of functions
into the base library. Before taking this step, maybe you should
think of merging all of the existing XML libraries into 1 (or possibly
2) larger libraries. If you can't get the developers to even agree on
whose version of a function should go in that (because of slight
differences that break this app or the other), then you are likely
going to run into the same decisions and hair-pulling for glibc,
except easily a thousand
This is another one of those classic "We need more Info" Ask Slashdot's.
No, this is nowhere near the classic "we need more info" ask slashdot. If you want
to win the classic crown, it has to read more like this:
Hi. (As will soon become obvious) I don't know anything about the
subject matter, I haven't done any investigation (not even a google
search...), I'm not sure (1) exactly what I need it for or (2) how
large scale it needs to be, or (3) how fast it needs to be, or (4)
what it will be hooked up to, or (5) where it will be installed, or
(6) why anyone would want such a thing...
but, could you call out every expert on the planet in all
fields to help me find the optimal solution and lay out a complete
project plan as part of a detailed rollout strategy that leads to a
leveraged vendor selection solution synergized with our quarterly
goals, marketing plan, corporate vision and political partnerships?
Thanks. By the way my sis says she is also curious. I have to go now my dog is barking.
that will by extension make it easier for Oracle to sell their own db
into the whole package
Sure, they may lose some DB2 deals, but they also stand to
gain Websphere deals from many Oracle clients who were using a
competing product that they now realize is exposing them to
single-sourcing risk. The wiser clients will be looking at the
technologies on the horizon and how that will play out in terms of the
flexibility they will have in future upgrades. They may be worried
that a specific technology will work to lock them in and take away
their option to walk away from a future licensing negotiation.
Basically, what IBM is saying here is "See, we are willing to leave
your options more open than the other solution."...And what's to say
that some Oracle clients, after moving to Websphere, won't then be
convinced to switch to DB2 if Oracle puts them on the treadmill? So,
from the vendors' perspective it is mostly a wash, and from the
clients' perspective, it leaves room for viable options (possibly Sun
java) or a positioning that allows them to partly (or completely)
switch to open source as a future option.
Common functions are exactly what glibc is for, maybe this is a good
idea.
Common functions are exactly what ordinary libraries are for. It
doesn't sound like you are distinguishing glibc, "the mother of all
libraries," sufficiently from any other library that can hold common
code.
If you want to bulk up glibc specifically, you should first try to
prove that it's a "need to have" along the lines of how "string" or
"streams" or "math" or "socket" are. If it's just someone's "nice to
have," or a frequently changing standard that needs frequent updates,
then it should probably remain where it is, in a separate library
devoted specifically to one purpose that can be easily identified and
upgraded every time the standards' board has an itch, or a bug or an
exploit is found.
There are already piles of XML libraries on the typical Linux
system, which you can verify by typing "ls *xml*" within your favorite
lib directory or perhaps "locate xml". Since this functionality
already exists so ubiquitously outside of glibc, why do you feel it is
necessary to add another copy, and to the base library on which
almost all executables depend? Do you expect all executables to need
XML?
Supposing that you manage to change it, what is your guarantee that
anyone will now want to use the XML functions therein, instead of the
ones in the library they have already tested with? Won't it be more
convenient for the developer to do nothing, rather that switch
everything over for no gain in functionality, and to risk getting hit
with unknown bugs? Wouldn't that chunk of library code in glibc
simply go ignored and only take up space? You can bring a horse to
water, but how are you going to force it to drink?
Also, won't this cause a situation where you now need to upgrade
several libraries to keep your applications working since some
of them use the glibc one and others use the non-glibc one, while the
non-glibc ones still depend on the previous version of glibc which you
have now switched out? Won't this lead to a possible library deadlock
mess?
So, given the severity of the issues that could be caused by
changing a base library, and the questionable benefits of doing so, do
you still think this is a good idea... for glibc?
There is an additional dynamic with OSS that is absent with most
commercial software, and so it isn't talked about much by the
institutionals. Since OSS is typically free, when innovation does
occur, the cream rises to the top quickly and spreads widely to
everyone who needs it. With commercial software, some may balk at the
price, and others don't want to bother with extra licensing. It can
only spread from a central point outward guided by central marketing, rather
than from peers guided by (decentralized) consulting or advice. Still others want to
try out commercial software but don't know if they need it, so they
never try it. OSS, in contrast is free to try and free to buy, so
there is little to hold it back, fewer restrictions and less
maintenance forced upon people when they do decide to use it.
Therefore, whatever innovation occurs is greased by these wheels and
potentially benefits a much larger group of people than otherwise.
Just think, all of this and without the need for a $100 million ad
budget or a pack of lawyers to write or interpret EULAs to protect IP.
The article tries to convince people that large companies innovate,
but it fails to mention that these companies also get R&D tax breaks
for exactly that purpose. So, whatever advantage closed source
appears to have should be taken with that adjustment in mind, that
they some extra help that the OSS people don't get.
While it's kind of neat to have an i-searchable buffer, be able to
attach pipes to all kinds of things you didn't know existed, eshell is
still a bit green (at least in my version of it). There are a few
defaults that I (and apparently a sibling post) found annoying.
First, when you try to edit a command you had previously typed
(e.g. command line editing, ^P) it instead moves you up a line in the
(fully editable) buffer, so that you find yourself in the output of
the previous command. So, you soon learn to use esc-P instead. Then,
if you go to the start of a line with ^A, instead of going to the
start of the command line as usual, it puts you at the start of your
shell prompt (ugh -- how often do I want to edit that?) I realize
this keeps things more or less generalized, but these defaults are
apparently there to motivate people to customize their copy of emacs.
With enough customization, eventually we'll be watching ascii
movies in an emacs pane and be able to use vi keys to fast-forward
past the commercials:) But don't say it too loud, as the RIAA might
put this on their emerging threat list, along with that internet 3
thing that we were supposed to keep hushed up about.
So unless you are complaining that 266mhz PII and 128mb of RAM are too
high system requirements, then you really don't know what you are
talking about.
Don't blame me, I'm just going by what I've been told by the
official press releases. A PC World review said here:
[Microsoft] advises getting 512MB of RAM and a "modern" CPU--more than
Windows XP needs
Past experience with prior releases from this vendor has shown that
if they say 512M, you will probably really need more than that. As far as the video requirements, don't blame me, this is what a
WinHEC reviewer had to say about it in this article:
for those with an older video card, Longhorn will look a lot like
Windows 2000
So, if you had been hoping to get a sample of all that wonderful
eye candy technology that we're supposed to be all hyped up about, the
sad fact is that you didn't really get to see it. Aw... You have
posted here to rave about the look and feel of a new Windows 2000
theme. Congratulations.
The same article mentions:
The top-of-the-line interface... will demand a high-end video card
with at least 64MB of video memory
Note how it says "at least." So, I'm left to wonder whether the
128M you were talking about wasn't what you had in your video card
instead of the motherboard.
So, then, I went to Tom's hardware, and found this:
Windows Vista's new display driver model may compel users to upgrade
to a PC with 2 GByte of DDR3 SDRAM and a graphics card with at least
256 MByte memory [...] As for system RAM, Page reportedly said, 512
MByte is "heaps" for a 32-bit system. For a 64-bit system, however,
"you're going to want 2 gigs of DDR3 RAM."
I can only conclude from this that you know more about this than
Tom's Hardware and PC World and News.com. 128M indeed!
Oh, and we were running some of the 2D and 3D WPF applications on it,
and they even worked.
Great to hear that your beta software actually runs. That's some
high standards there.
As it stands now, the technologies Microsoft are starting to disclose
to its partners and Developer are bombshells of technology
I'm so excited for their partners. Those lucky partners must
really be on the floor hyperventilating in an epic fashion. And I
thought it was just an overmarketed eyecandy-riddled program launcher
disguising a rat's nest of hidden vendor lock-in schemes. But it
launches bombshells too? Now that's exciting... There wouldn't
be any pterosaurs flying around nearby would there? (Never mind
that.)
especailly if people in here are trying to even remotely keep up with
the R&D that has been producing this stuff in some hidden closet for
the past 5 years.
Stuff classified as R&D expenses qualify for tax breaks don't they?
So you're saying that we're actually paying twice for this
thing, even if we choose not to use the convicted monopolist's lock-in
product? We're almost as lucky as their beta testers, er I mean
partners.
other parts of Linux and BSD that are only scrambling to catch up to
Windows
Really? Tell us more about this modern technology you would like to
see in Linux and BSD. No doubt I can read more about it in your
newsletter.
Until linux starts offering the same in 5 years. Then you'll be
praising it.
Not everything that glitters in 3D is necessarily an advance
and an example to be followed.
In fact, due to the heavy duty video card needed for this "upgrade"
along with other parts, systems are predicted to require a 1000 watt
power supply. Just think of the extra generating capacity demanded of
the world electrical system to supply the millions of users upgrading to this. The extra energy consumption will be an unwelcome
shock to a world already faced with high energy prices and low energy
supply.
Some quick figures:
Assume 100 million people upgrading (if every user bites)
Assume average 700W increase in power requirements (300W to 1000W)
100 million * 700W = 70 Gigawatts
Converting 70 Gigawatt hours to BTU, we get 2.3884991e+11 BTU
Assume 5.8e6 BTU per barrel of oil
2.3884991e+11 BTU / 5.8e6 BTU/bbl = 41181 barrels per hour, or
Over 15 million barrels of oil per year
In 5 years, that will use up 75 million barrels, or
$5.25 billion at the current price of US$70/bbl (wholesale)
That's $52.50+ nominal extra energy cost per user
So, a single decision by one company to spec one product this
highly could require 70 Gwh of new generating capacity, take an extra $5 billion out of the world economy and cost
roughly $50 per user in extra energy costs. More likely, however, is
that the price of energy will be sent up even higher by this change.
IMHO, we need this like we need another natural disaster.
Verbal gymnastics to compare well vs google
on
Bill Gates Speaks Out
·
· Score: 3, Insightful
Billgatus of Borg:
In fact, they have this slogan that they are going to organize the world's information. Our slogan is...
In google's own words:
Google's mission is to organize the world's information and make it
universally accessible and useful.
(my emphasis added)
Note how Billgatus of Borg conveniently omits the part about making
it universally accessible, as if to avoid an embarrassing
contrast between Google's track record and the constant roadblocks his
own company puts up.
While Google was building its business with open
standards and on the same level playing field that other search
engines could use, MSFT was exploiting the closed nature of its Word
format against its competitors. While Google was busy adding support
for a wide variety of browsers, MSFT was breaking HTML standards in
the hopes that only IE would remain standing. He
had to leave that little detail out, otherwise it would dredge
up memories of how MSFT became a convicted monopolist, and that would
clash with the sparkling Mr. Clean image he was trying to
project.
And useful? I certainly find it more useful if searches return
what I'm searching for instead of just ads. If MSFT manages to kill
Google, I would expect search results to degenerate back to the
highest bidder model of ads mixed into the search results. Google has
done a much better job of managing their PR with this, steering clear
of hotmail-like flashing ads and pagerank gambits and maintaining some
semblance of believability. And, they've done it without pulling
their hair (or toupees) out, or throwing chairs or lodging the sort of
epithets one would expect from a knuckle-dragging world wrestling
federation circus act. It's a contrast that had to be swept under the carpet.
So, how does The Collective answer to Google's mission statement?
(voice=polyphonic Borg collective + squeaky Billgatus)
Our slogan is that we are going to give people tools to let them
organize the world's information...
(and I would sardonically add)...in a EULA-bound fashion, so that we can revise the agreement at any time to, in effect, appropriate the intellectual property rights to ourselves, without
having to spend a cent storing it. It shall all be
assimilated. Eventually people will have to buy our systems just to
access that information and Google will find itself locked out by our
DRM. Resistance is futile. (/sardonicity)
Also, what's this talk about "giving" tools to people? My, how
generous that sounds. Does he mean like another toolbar? Gee,
thanks. Or perhaps he means a tool in the sense of a talking
paperclip? Or maybe a 3-D flipping crowbar to open up those DRM files
long enough to read their EULAs? Or how about a free spyware remover
that doesn't remove the #1 brand of spyware, which has a EULA claiming
it is illegal to try to remove it. Hmmm. Everyone bow to the
unbounded generosity?
One thing's for sure, Google's API has gotten onto his radar, so
I'm guessing they may also try to beam down another shipment of
EULA-laden developer tools in the hopes they can cut Google off at the
mindshare pass. They are trying to kill Google, but for the
moment it looks like they will have to brainwa^Wtrain a lot more
nine-year-olds. Anyone who knew what was going on a scant few years
ago and strains long enough to remember it would have to conclude that
this is just another whitewash.
You're going to bump up against the upper-limit of the filename
length...and your filename solution breaks down
I can think of several ways to solve this offhand. If your filesystem has a
fixed filename limit, or you can't tune your filesystem to increase the filename
length, you can still store each email as a directory, with each field as a
separate file within it, side-by-side with the message. If you don't want to do
that, you can store as much as will fit and spill over longer fields to the message
itself. Or, just have shorter fields. You could have a client-side address book
that maps a hash id to recipient email address, etc. (There are a bunch more ways but I'm not
going to bore you with them.)
go to '/usr/bin' on a Unix system... Notice how slow BASH is at retrieving the
results?
No:) It was quite fast for me. You must be doing something wrong.
Even if it is slow for you, your client won't typically be looking at a
directory filled with a million little files (a disingenuous example if I may say
so), because it will be smartly broken down into subcategories.
Hallelujah, he finally gets it! Yes, index everything... The
amount of storage for this would be the one-time cost of the word plus
4-8 bytes for each instance of the word found across the entire
filesystem.
Everything, eh? Well, if your entire filesystem is on a SAN, that's one huge
global index that has to span a single immense partition for 1 million users. The
index would be so big that you would likely not be able to fit the entire thing
within the RAM of a single server. If that happens, your system is in even more
trouble than I thought earlier. I figure a 1 million user system will have to
handle 100 million incoming emails a day, most of them during the morning peak.
So, the SAN drives have to keep revisiting the index even for reads, not just for
writes. And all that just so you don't have to store the word viagra in a million
different places. That is, DBFS will be slow unless it has some form of
distributed filesystem capabilities.
Ideally, the head would never leave the platter while reading in the
index, as opposed to studying each file on disk
You want to keep re-reading the index from disk, rather than from cache?
That doesn't sound like the ideal or best case. The ideal is to avoid as much disk
access as possible.
I will glean from this that there are no benchmarks yet...
updating the index is a minor amount of data to commit
But the disk head has to move far away from where it was just to
update a tiny thing. That's fine for a one-user system, but for a large
email system it can gum up the works very quickly.
Remember, I'm not advocating the use of a database on top of a filesystem
Don't worry, I may be dense, but that much has sunk in. I can
sympathize -- freeing you from your subdirectory inhibition has been
just as difficult.:)
I actually suggested using FUSE to stick the file system in userspace
Yeah, it's either run in userspace or you will have a huge index (filled with
stuff like viagra1, v1agra, etc.) that you can't swap out. But the downside is
that you've replaced the base of your information pyramid (that ought to be stable
enough to build on) with an unproven component. It also doesn't improve matters
that this new filesystem is multithreaded if you're trying to debug a file or
index corruption issue. While that's happening all 1 million users will be waiting for the system to come
back up, because for the global index to remain
consistent, the entire system has to go down if only a part of it has failed.
Slashdot Mirror
Actually, they will use the opportunity to make 1000 clones of you for their clone army but forget that these people have jury duty, and so they will all show up as jurors claiming they have never met you before. You will thus be acquitted but will be mistaken for someone else because your DNA matches, so that you are then sent to Afghanistan, where you will be placed on landmine removal duty. In the meantime, the soldier-clone you displaced is arrested trying to board a military transport and, obviously an impostor, is sent to jail, where the process starts all over again.
As millions of copies of you begin to spread all over the Earth, nobody is the wiser when you manage to elect yourself as president. With majorities in all political bodies, you and your clones pass a law banning the forcible collection of DNA.
~The End~
I find your lack of faith disturbing. Are you *gasp* criticizing the unassailable accuracy of the official computer press? (Shhh... speak only in whispers, comrade, for I hear the sound of boots in the distance...)
That was originally your example, not mine.
You miss the original point. Top of the line or no top of the line -- having a video card under load all the time is going to draw a $#!%-load of extra power off the grid when you multiply that against millions of computers. In many cases, it will double the average power draw of each. That's not particularly helpful now with the price of fuel going up. Or becoming scarce. Whether the number of computers that can have this running is 50 million (fast ones) or 200 million (slow ones), you can debate the specific tiers all you want but the original point of profligacy still applies.
Before this change, only a minority of the world's people would be putting their video cards at full load at any given time. Now it will be practically every computer in every office in the world. And, as one of the articles points out, the productivity returns of 3D office apps are not only diminishing, they are arguably nonexistent. There is no real gain for this energy waste, so why keep fooling people? They will be unexpectedly surprised when they get their energy bill, or angry if it causes a blackout, or worse if heating oil runs out in the winter because some TOP OF THE LINE people wanted to see 3D flying monkeys coming out of their Orifice application.
You're still saying 64M of RAM on the video card, while Tom's Hardware says you will be compelled to get at least 256M on the video card. That's quite a margin. You two disagree by over 4x. Why should I believe you instead of Tom's? And why would PC World not report the correct figure that MSFT themselves gave them?
A virus scanner by itself will use up that much. You obviously have no idea what people will use it for in the real world.
Or, maybe $200 later a lot of us would only find out that your claims are false because all of the traffic to the system bus is being tied up by the video card in order to do those fast-looking 3D operations. I predict that on an AGP motherboard, simultaneous disk I/O will turn to molasses because the bus will be saturated by the video traffic. That is the true system bottleneck being slowed there. It will be slower than the previous operating systems for real work. Some improvement! And when WinFS comes along, the CPU or chipset will have to constantly encrypt and decrypt every damned thing on the disk, loading new machines even more and slowing older ones into doorstop status.
This will force people to upgrade their computers and you know it. And it will get hot in those offices. Or should I call them sweatshops by now, because you'll have CPU + chipset + video card all churning away under full load, drawing excess power and generating heat. Lots of heat. It will be like HELL :)
Sure, but do you use whips and pitchforks on them?
While I agree with you that Apple has done it more often than Winblows, you also seem to be ignoring a little something called the Amiga, back when most operating systems were still single-tasking and video editing required a supercomputer. I'm curious what you thought of that, or if you had ever heard of such a thing. Was it really innovative, or are the various versions of history being proposed here all being edited for the general audience?
Well, but suppose 100 years from now we learn how to capture a small planet and place it in earth orbit. Does we stop calling it a planet at that point?
Google TPCA, TCG, TPM. Quite real and already here, unfortunately. The operating systems to use TC features are almost here. Anonymous bloggers in repressive regimes would need to begin worrying about it already, so they can make the right purchases and avoid the wrong ones. Once the full system is in place, it will be too late and it will seem strange to be seen buying old hardware.
It's theTPM chip that implements the TC spec. Almost all x86 motherboards for sale today have taken the TPM functionality and integrated it into the chipset or CPU so it is no longer a separate chip. Read about your favorite new motherboard chipset and (if the PR people haven't hidden it by now) then compare older chipsets with the newer ones -- you will see the newer ones all claim to have a "security" feature of some kind. Try to find any details of the feature. Hint: they are no longer bragging about it like they used to.
The unique ID is in the TPM itself. It is never released to you, the supposed user, despite the fact that you supposedly own the computer. If you want to read about this in detail, you will need to read a lot and keep an open mind because there is a lot of PR in the way of the facts.
There's more about this from this previous story
It seems the "open" file format XML is a busy place for them to unload their proprietary patents. If someone built a freeway, I'm sure these jokers could figure out a way to place their own toll booth in the middle of it.
The only trouble with that is that our own Moon is bigger than pluto. Our satellite has a radius of 1738 km versus 1195 km for the Kuiperplanet.
Compare NASA's moon factsheet with their pluto factsheet
First, it looks like the moderators who said I was offtopic in the GP haven't taken the trouble to investigate Trusted Computing thoroughly enough. It is as relevant as anything else on here.
Now I will have to explain myself in more detail. Those who don't believe that your computer will gain the ability to betray you should perhaps begin by reading this, where it said that...
My emphasis. In short, applications will be able to hide data from users. Since then, there seems to have been a tendency to try to occlude the natural meaning of "user" so that this capability is not obvious, but in 2003 nobody understood TC well enough to worry about the controversy, so they had it in the correct context. Amazing, huh? Now, back to what I was going to post...
If TC hasn't been taken into account by the brochure, I worry they may ignore some of the finer implications. To begin with, applications on your own computer (not necessarily the connecting computer) will be able to store information about what you are doing and when and to "protect" it, without giving you the ability to look at that information yourself or to even know where it is stored. If the reporter is ever caught, the reporter may not know that there is incriminating information hidden on her own computer. So, it is no longer enough to just destructively delete a browser cache or something and be reasonably certain nobody can prove you authored a message. And, have you checked what data spyware may be sending out of your computer -- now with your unique, attestable identity attached to it?
So, if the brochure doesn't address that, it's only good for a short time.
The AC seems to be saying that the source of a comment can be hidden by bouncing it around to different places, so that the destination site cannot tell where it came from, and so that the service at the source cannot tell it is a disparaging comment until it is already posted. Well, that assumes that all of the intervening sites aren't cooperating, and they may have to cooperate in order to remain in business in a given country. Since the identities of the people sending traffic to cooperating sites will be known up to the point where the traffic reaches a non-cooperating site, anyone constantly sending traffic to a non-cooperating site will be investigated more closely. If the result of the investigation narrows it down to a few people, then all of their computers can be searched to reveal the reporter.
So, it may not be impossible to remain anonymous but it becomes risky and harder, and with technologies that are meandering this way, becomes near impossible.
Eventually the only solution may be to spread a rumor to a bunch of people you dislike and hope they type it for you :)
tropical storm Pi: Every time I tell the residents here that the storm is coming I am roundly criticized. I tried to convince them to leave but they are diametrically opposed.
Hurricane Lambda: Nobody could'a predicted that we would see a recursion of storm activity so soon after tropical storm Kappa headed back out into the gulf. It just seems to keep returning. Everywhere people are asking "when will we have closure?" but there is no result, just a bunch of empty arguments. As for me, I'm going to pass on those.
Only valid where doing so is not a crime (even if the only thing they charge you with was that you were viewing porn).
Are you saying that there are no fatal flaws in either of the parsers you mention and that you heartily recommend that very very large XML documents be used liberally and frequently with both by large installations, because it is not required to keep the documents fully in memory with either?
Or, is the parent unfamiliar because "everyone knows" they should not be using a parser with a design flaw that can be exploited simply by introducing a huge document? Then why is the flawed parser still in the standard if "everyone knows" it is flawed? Is it because "everyone agrees" the other one has its own flaws, so as to try to avoid that by default?
If neither is a good solution, do you know of several other parsers or alternate APIs that should be added to the standard to help make sure that one of them will be of use to everyone in all situations? Or, should customization like that be discouraged so that the number of parsers and APIs is kept only to those that everyone knows about?
Thanks for noticing. This whole idea of what causes people to come to heated disagreements is an interesting science, in and of itself. If you see me casting insults, maybe it is just because I am researching the state of the art :)
On the other hand, the argument that it's infinitely better for that purpose hasn't been proven to everyone conclusively. You may know of a link that makes a better case, but thus far, I have only seen a lot of hand waving, like: "Oh, it can be made to boot faster on hardware that is lightning fast anyway and coincidentally has had other booting impediments systematically removed and deserialized." That's like saying we added (3 + e^1000) and got a really big number, therefore the 3 deserves the credit for the bigness in the result because, not only did it come first but it is the topic of the article. So you could argue on and on about the quality of the horseshit on this side, or the merits of the horseshit on that side, but the real difference is that one of them is bursting out at high pressure, and you can instantly spot which one because it's the one with the marketing push and the buzz surrounding it.
I recognize XML may make sense for other folks. Companies like Apple can sign cross licensing deals with XML patent holders like MSFT to shield themselves from negative IP impacts in the future, but OSS can't do that because it's not a patent-owning corporation, and it is already giving its stuff away. Since MSFT has marked Linux as its enemy, a push for ubiquitous XML on Linux or other sweeping ideas that appear to come out of nowhere are best taken with a grain of salt. The source of the push may not necessarily be founded on good engineering principles. So, if the engineering impacts aren't strongly positive, people can afford to watch from the sidelines.
Is the XML standard likely to stabilize any time soon? There is the hidden danger that, once in place at the system choke points, you are basically allowing a standards body with no understanding of OS internals to indirectly design the future of posix operating systems. "We decree your library should add 15 more parsers and store them unswappably in RAM." "We decree that you use an 32 byte per character representation of text." "We decree that you add XML 'accelerating' hardware to your system." (In effect:) "We decree you follow the pace of our planned obsolescence cycle." All that, and eventually someone shouts "software patent violation" and pulls the rug out from under you. (Not that it will all come true but that it's wise to ask "who benefits" and use the "follow the money" maxim.)
XML is hierarchical. Structured hierarchies, while simplifying and appropriate in many cases fail at both extremes: the case of a trivial app in its formative stages and the case of a super-complex app. A trivial app's designer will balk at reading API documentation just for a one-page daemon's configuration, when a text file with a port number in it takes 5 seconds. The super-complex app designer may not mind reading several APIs but will eventually need a configuration that is executable in its own right -- a scripting language. So, if you are going to make a substantial change in the infrastructure of an OS, why not plan for the long term? If XML will be transformed into a scripting language, how readable will it ultimately be?
I haven't had time to read the RSF brochure, but does it explain what to do if you have a TC setup (a computer that can attest to a unique identity like CPUID but more unique than that) so that all messages can be traced back to the computer that sent it?
It sounds like their suggestions would only be useful for a short while, until all computing equipment is replaced with TCG-compliant stuff, (or even before, by using an older case to contain a new computer). If anonymous bloggers are not careful, someday they will be nabbed.
I wonder if this will usher in a new era of strict dictatorships and unparalled oppression? We may never know, since no one may be able to report about it :)
No, IMHO what we have is heaven compared to a situation where we have the additional headache of switching out glibc as well. You can change the other libs out without a reboot and without impacting non-XML software, which is about 99.9999% of it. Why should unrelated software and services be interrupted just because someone decided on this standard without discussion of other, possibly better ones that may come along? We don't need to make this like Winblows where every install of an IM client requires a reboot. We should be moving away from that approach. It is inconvenient to desktop users as well as the server people. Even they have admitted by now that they were wrong on this one...
But... somebody has to rewrite and test all of those libraries to make them all consistent with each version of glibc that is released. If they are consistent with one, they will almost certainly be inconsistent with the other. So, depending on what is added, you could create more of a 'dependency hell' scenario than where you started. Dependency hells are best resolved though open communication of the library architects and developers. Glibc is not a magic bullet that solves all dependency problems, it will require even more consensus to achieve that goal.
So then you would need both an fstab and an fstab.xml, to make sure that your machine can boot after the upgrade, and so that it can still boot if you need to downgrade (because maybe the new glibc broke something unexpected, so you keep it around as a backup...) Then the glibc will have to have the tiny fstab parser plus the XML version N parser (more complex and 1000 times bigger?) in order to be gracefully backwards compatible when booting from a filesystem where someone left out the fstab.xml, so as not to be locked out.
So, glibc will not really be reduced or simplified by this change, it will only grow, duplicate effort and become harder to maintain. Then, of course, you may need to downgrade to the old glibc a long time later and forget that you need fstab for that version and maybe only be stuck with fstab.xml by that time, so that your system will not boot, and you will have to do a bunch of hunting around for what is supposed to be in XML and what is not and then a bunch of reconfiguring work in addition to the library changes before you can boot. Finally, I suppose some people will end up with both fstab.xml and fstab side by side and will not know which of the two is the effective one at any one time, leading to unpredicable behavior. In some cases people will end up needing to hire a consultant to figure out what's going on with their systems.
That's the point. You want your base library to change as infrequently as possible. If you don't change the base library, you don't have to be recompiling everything all of the time. With a separate XML lib, you only have to recompile the apps that depend on that lib. If you already have dependency problems with those, those should be completely resolved and the differences hashed out between the contenders before even beginning to discuss inclusion of functions into the base library. Before taking this step, maybe you should think of merging all of the existing XML libraries into 1 (or possibly 2) larger libraries. If you can't get the developers to even agree on whose version of a function should go in that (because of slight differences that break this app or the other), then you are likely going to run into the same decisions and hair-pulling for glibc, except easily a thousand
Sure, they may lose some DB2 deals, but they also stand to gain Websphere deals from many Oracle clients who were using a competing product that they now realize is exposing them to single-sourcing risk. The wiser clients will be looking at the technologies on the horizon and how that will play out in terms of the flexibility they will have in future upgrades. They may be worried that a specific technology will work to lock them in and take away their option to walk away from a future licensing negotiation. Basically, what IBM is saying here is "See, we are willing to leave your options more open than the other solution." ...And what's to say
that some Oracle clients, after moving to Websphere, won't then be
convinced to switch to DB2 if Oracle puts them on the treadmill? So,
from the vendors' perspective it is mostly a wash, and from the
clients' perspective, it leaves room for viable options (possibly Sun
java) or a positioning that allows them to partly (or completely)
switch to open source as a future option.
Common functions are exactly what ordinary libraries are for. It doesn't sound like you are distinguishing glibc, "the mother of all libraries," sufficiently from any other library that can hold common code.
If you want to bulk up glibc specifically, you should first try to prove that it's a "need to have" along the lines of how "string" or "streams" or "math" or "socket" are. If it's just someone's "nice to have," or a frequently changing standard that needs frequent updates, then it should probably remain where it is, in a separate library devoted specifically to one purpose that can be easily identified and upgraded every time the standards' board has an itch, or a bug or an exploit is found.
There are already piles of XML libraries on the typical Linux system, which you can verify by typing "ls *xml*" within your favorite lib directory or perhaps "locate xml". Since this functionality already exists so ubiquitously outside of glibc, why do you feel it is necessary to add another copy, and to the base library on which almost all executables depend? Do you expect all executables to need XML?
Supposing that you manage to change it, what is your guarantee that anyone will now want to use the XML functions therein, instead of the ones in the library they have already tested with? Won't it be more convenient for the developer to do nothing, rather that switch everything over for no gain in functionality, and to risk getting hit with unknown bugs? Wouldn't that chunk of library code in glibc simply go ignored and only take up space? You can bring a horse to water, but how are you going to force it to drink?
Also, won't this cause a situation where you now need to upgrade several libraries to keep your applications working since some of them use the glibc one and others use the non-glibc one, while the non-glibc ones still depend on the previous version of glibc which you have now switched out? Won't this lead to a possible library deadlock mess?
So, given the severity of the issues that could be caused by changing a base library, and the questionable benefits of doing so, do you still think this is a good idea... for glibc?
There is an additional dynamic with OSS that is absent with most commercial software, and so it isn't talked about much by the institutionals. Since OSS is typically free, when innovation does occur, the cream rises to the top quickly and spreads widely to everyone who needs it. With commercial software, some may balk at the price, and others don't want to bother with extra licensing. It can only spread from a central point outward guided by central marketing, rather than from peers guided by (decentralized) consulting or advice. Still others want to try out commercial software but don't know if they need it, so they never try it. OSS, in contrast is free to try and free to buy, so there is little to hold it back, fewer restrictions and less maintenance forced upon people when they do decide to use it. Therefore, whatever innovation occurs is greased by these wheels and potentially benefits a much larger group of people than otherwise.
Just think, all of this and without the need for a $100 million ad budget or a pack of lawyers to write or interpret EULAs to protect IP.
The article tries to convince people that large companies innovate, but it fails to mention that these companies also get R&D tax breaks for exactly that purpose. So, whatever advantage closed source appears to have should be taken with that adjustment in mind, that they some extra help that the OSS people don't get.
You can also try eshell (emacs shell) and py-shell (python shell). Where else do you have reusability like the following?
And consider that all of the elisp commands have command completion, so that typing longer commands:
...aren't such a big chore.
While it's kind of neat to have an i-searchable buffer, be able to attach pipes to all kinds of things you didn't know existed, eshell is still a bit green (at least in my version of it). There are a few defaults that I (and apparently a sibling post) found annoying.
First, when you try to edit a command you had previously typed (e.g. command line editing, ^P) it instead moves you up a line in the (fully editable) buffer, so that you find yourself in the output of the previous command. So, you soon learn to use esc-P instead. Then, if you go to the start of a line with ^A, instead of going to the start of the command line as usual, it puts you at the start of your shell prompt (ugh -- how often do I want to edit that?) I realize this keeps things more or less generalized, but these defaults are apparently there to motivate people to customize their copy of emacs.
With enough customization, eventually we'll be watching ascii movies in an emacs pane and be able to use vi keys to fast-forward past the commercials :) But don't say it too loud, as the RIAA might
put this on their emerging threat list, along with that internet 3
thing that we were supposed to keep hushed up about.
Don't blame me, I'm just going by what I've been told by the official press releases. A PC World review said here:
Past experience with prior releases from this vendor has shown that if they say 512M, you will probably really need more than that. As far as the video requirements, don't blame me, this is what a WinHEC reviewer had to say about it in this article:
So, if you had been hoping to get a sample of all that wonderful eye candy technology that we're supposed to be all hyped up about, the sad fact is that you didn't really get to see it. Aw... You have posted here to rave about the look and feel of a new Windows 2000 theme. Congratulations.
The same article mentions:
Note how it says "at least." So, I'm left to wonder whether the 128M you were talking about wasn't what you had in your video card instead of the motherboard.
So, then, I went to Tom's hardware, and found this:
I can only conclude from this that you know more about this than Tom's Hardware and PC World and News.com. 128M indeed!
Great to hear that your beta software actually runs. That's some high standards there.
I'm so excited for their partners. Those lucky partners must really be on the floor hyperventilating in an epic fashion. And I thought it was just an overmarketed eyecandy-riddled program launcher disguising a rat's nest of hidden vendor lock-in schemes. But it launches bombshells too? Now that's exciting... There wouldn't be any pterosaurs flying around nearby would there? (Never mind that.)
Stuff classified as R&D expenses qualify for tax breaks don't they? So you're saying that we're actually paying twice for this thing, even if we choose not to use the convicted monopolist's lock-in product? We're almost as lucky as their beta testers, er I mean partners.
Really? Tell us more about this modern technology you would like to see in Linux and BSD. No doubt I can read more about it in your newsletter.
Not everything that glitters in 3D is necessarily an advance and an example to be followed.
In fact, due to the heavy duty video card needed for this "upgrade" along with other parts, systems are predicted to require a 1000 watt power supply. Just think of the extra generating capacity demanded of the world electrical system to supply the millions of users upgrading to this. The extra energy consumption will be an unwelcome shock to a world already faced with high energy prices and low energy supply.
Some quick figures:
So, a single decision by one company to spec one product this highly could require 70 Gwh of new generating capacity, take an extra $5 billion out of the world economy and cost roughly $50 per user in extra energy costs. More likely, however, is that the price of energy will be sent up even higher by this change.
IMHO, we need this like we need another natural disaster.
Billgatus of Borg:
In google's own words:
(my emphasis added)
Note how Billgatus of Borg conveniently omits the part about making it universally accessible, as if to avoid an embarrassing contrast between Google's track record and the constant roadblocks his own company puts up.
While Google was building its business with open standards and on the same level playing field that other search engines could use, MSFT was exploiting the closed nature of its Word format against its competitors. While Google was busy adding support for a wide variety of browsers, MSFT was breaking HTML standards in the hopes that only IE would remain standing. He had to leave that little detail out, otherwise it would dredge up memories of how MSFT became a convicted monopolist, and that would clash with the sparkling Mr. Clean image he was trying to project.
And useful? I certainly find it more useful if searches return what I'm searching for instead of just ads. If MSFT manages to kill Google, I would expect search results to degenerate back to the highest bidder model of ads mixed into the search results. Google has done a much better job of managing their PR with this, steering clear of hotmail-like flashing ads and pagerank gambits and maintaining some semblance of believability. And, they've done it without pulling their hair (or toupees) out, or throwing chairs or lodging the sort of epithets one would expect from a knuckle-dragging world wrestling federation circus act. It's a contrast that had to be swept under the carpet.
So, how does The Collective answer to Google's mission statement? (voice=polyphonic Borg collective + squeaky Billgatus)
(and I would sardonically add) ...in a EULA-bound fashion, so that we can revise the agreement at any time to, in effect, appropriate the intellectual property rights to ourselves, without
having to spend a cent storing it. It shall all be
assimilated. Eventually people will have to buy our systems just to
access that information and Google will find itself locked out by our
DRM. Resistance is futile. (/sardonicity)
Also, what's this talk about "giving" tools to people? My, how generous that sounds. Does he mean like another toolbar? Gee, thanks. Or perhaps he means a tool in the sense of a talking paperclip? Or maybe a 3-D flipping crowbar to open up those DRM files long enough to read their EULAs? Or how about a free spyware remover that doesn't remove the #1 brand of spyware, which has a EULA claiming it is illegal to try to remove it. Hmmm. Everyone bow to the unbounded generosity?
One thing's for sure, Google's API has gotten onto his radar, so I'm guessing they may also try to beam down another shipment of EULA-laden developer tools in the hopes they can cut Google off at the mindshare pass. They are trying to kill Google, but for the moment it looks like they will have to brainwa^Wtrain a lot more nine-year-olds. Anyone who knew what was going on a scant few years ago and strains long enough to remember it would have to conclude that this is just another whitewash.
What would Admiral Shlork do if presented with this choice?
http://www.pbfcomics.com/temporary/PBF013ADAdmiral Schlork.html
Warning: not for the faint of heart. And the link might disappear eventually.
It's worth reading that page for a good laugh though. A link to it: http://www.sigmaautomotive.com/IRD/superfuelmax.ph p
If you're looking for something real, I think Valeo (recently had a piece on lemonde.fr) already has something along these lines.
I can think of several ways to solve this offhand. If your filesystem has a fixed filename limit, or you can't tune your filesystem to increase the filename length, you can still store each email as a directory, with each field as a separate file within it, side-by-side with the message. If you don't want to do that, you can store as much as will fit and spill over longer fields to the message itself. Or, just have shorter fields. You could have a client-side address book that maps a hash id to recipient email address, etc. (There are a bunch more ways but I'm not going to bore you with them.)
No :) It was quite fast for me. You must be doing something wrong.
Even if it is slow for you, your client won't typically be looking at a directory filled with a million little files (a disingenuous example if I may say so), because it will be smartly broken down into subcategories.
Everything, eh? Well, if your entire filesystem is on a SAN, that's one huge global index that has to span a single immense partition for 1 million users. The index would be so big that you would likely not be able to fit the entire thing within the RAM of a single server. If that happens, your system is in even more trouble than I thought earlier. I figure a 1 million user system will have to handle 100 million incoming emails a day, most of them during the morning peak. So, the SAN drives have to keep revisiting the index even for reads, not just for writes. And all that just so you don't have to store the word viagra in a million different places. That is, DBFS will be slow unless it has some form of distributed filesystem capabilities.
You want to keep re-reading the index from disk, rather than from cache? That doesn't sound like the ideal or best case. The ideal is to avoid as much disk access as possible.
I will glean from this that there are no benchmarks yet...
But the disk head has to move far away from where it was just to update a tiny thing. That's fine for a one-user system, but for a large email system it can gum up the works very quickly.
Don't worry, I may be dense, but that much has sunk in. I can sympathize -- freeing you from your subdirectory inhibition has been just as difficult. :)
Yeah, it's either run in userspace or you will have a huge index (filled with stuff like viagra1, v1agra, etc.) that you can't swap out. But the downside is that you've replaced the base of your information pyramid (that ought to be stable enough to build on) with an unproven component. It also doesn't improve matters that this new filesystem is multithreaded if you're trying to debug a file or index corruption issue. While that's happening all 1 million users will be waiting for the system to come back up, because for the global index to remain consistent, the entire system has to go down if only a part of it has failed.
DBFS sounds great for a small syste