Re:But is it because Linux is superior?
on
Linux Appliances
·
· Score: 3
Because Linux is divided into a kernel and discrete components, such as the C library, bash, command line utilities, etc., which can be easily separated and replaced with something else.
And BSD is divided into a kernel (made of descrete components), and a user land made of descrete components like the C library, various shells, command line utilities, etc., which can be easily replaced with other things.
Try again. Neither Linux nor BSD has an advantage in this area.
With *BSD, the OS distribution gives strong incentive to use what is provided in/usr/src and/usr/ports, to the exclusion of software not provided.
Well, yes FreeBSD at least provides a strong incentave to use what is provided, namely making it dirt simple to use that stuff. It doesn't make it any harder to use non-ports stuff then any other Unixlike OS. You can even use the FreeBSD package manager (which allows dependnecy tracking, and easy uninstall) with non-ports software. Of corse if you did, it would be a tiny step to make it "ports software" (namely a few text files).
But I have installed a lot of non-ports stuff on my FreeBSD box (mostly snapshots of newer-the-ports stuff). I don't see how it diffres from installing a "too-new-to-be-RPMed" package in Red Hat.
I would say no advantage between Linux or BSD in this area.
You're always going to have source code for something hanging around, and probably not something you intended to keep, and certainly not tarred and gzipped!
Yes, unless you master the mystical "rm" command, you will still have the tarballs after you "make clean" (rm/usr/ports/distfiles/* works pretty good). I do wonder why there isn't a cron job to clean old files out of/usr/ports/distfiles, but this is definitly someting almost anyone ought to be able to do on their own if they wish.
To build an embedded Linux operating system, all you need to do is build a Linux kernel, build a libc (e.g. glibc2 or newlib, and build whatever other tools you need, then combine them into a nice binary distribution. Even without a package mangler. I can't even begin to conceive of how one would build such a thing with *BSD without seriously disturbing the OS installation hosting the build process. I'm sure it could be done, but if it were that easy, someone would have done it by now.
I think the general thery under BSD would be to compile a kernel, libc, and the other tools you need, put them in in a binary distrubution (see the "mfsroot" tools). Even without the package manager, if it is offensave or useless to you.
For examples look at PicoBSD, the 1.44MB distribution, or maybe at the BSD in Juniper's M-series $100k+ routers, or at the BSD in Ascend's GRF routers. Or IBM's ePIPE, or Whissle's InterJet. Or, hell, the X-Terminals I built in 1992.
Again, Linux and BSD are pretty much the same in this regard.
Further, Linux is open source and open development. Anybody can participate. BSD is far less open source, and far less open development. Ever tried to submit a patch to a *BSD kernel? Ha, good luck. There should be no question as to why the BSD kernel keeps forking.
I don't see any reason why BSD is less "open source". It is "less GPL", and arguments can be made about whether that is good or bad. But it fits ESR's Open source Definition. I've had patches accepted by various BSD groups. I've had them rejected as well, and a better fix was taken in their place. I havn't made any Linux patches, but I hope (and expect!) the result would be the same, my well-written patches would be accepted, and my flimsy half-baked hacks would be rejected, and maybe done better by someone else.
As for the forking, I remain unconvinced that Red Hat, SUSE, Debian, Slackware, Corel, Mandrake, Trustix, Storm and Yellow Dog are really signifigantly more similar then FreeBSD, OpenBSD, and NetBSD. Yes, all the linuxes are a kernel that Linux blessed, plus (sometimes) patches, and diffrent config options. But the userlands are all diffrent. Just like the BSD userlands. And as far as portability goes that is about as bad. Which is to say, a slightly-more-then-minor problem for source shipped programs, but not a major huge super big showstopper problem (in either BSD or Linux!)
Even if convinced, I'm not sure it would be a wholey good thing. If userland devirsity is a good thing, why is not a little kernel diversity? I really enjoy having multi-CPU support in FreeBSD. On the other hand, when I want a really secure system, I appreciate Theo's stance that the multi-CPU stuff hasn't been around long enough to be sure there are no security-related race conditions in it.
Here we have the first non-tie. BSD is better if you are intrested in deversity at all levels. Linux is better if you want basically the same kernel everwhere, but don't care about the userland being quite so similar.
As for Linux vs. BSD, BSD advocates will say that it is technically superior in many areas, and be correct. However, Linux is far superior in at least one aspect: the manner in which it is developed. I expect BSD to be left in the dust in all technical areas that matter within a very short time, unless they can get their act together
Well, Linux does have Linus to keep everyone roughly on track. And that is a major big deal. BSD has nobody with the same leadership skills, who has stepped into the same sort of role.
On the other hand I wouldn't exactly say BSD has been left in the dust so far, and Linux has been around, what, nearly 10 years now?
Linux has gotten some really cool stuff recently (XFS, Riserfs being the most intresting), but BSD hasn't exactly been sitting still (look at the FFS soft update code, and the work-in-progress version of FFS that can do NetApp style snapshots, and live-filesystem-fscks). Linux seems to have gotten quite a leg up in fine-grained SMP, but with the recent Walnet Creak/FreeBSD/BSDI annoncment, I expect BSD can "catch up". After all Paul Borman allready did fine grain locking in Cray's TCP/IP stack, how hard could doing it twice be?:-)
My summary for this one would be "answer unclear, try agian next year". But I accept diffrent peple could judge this diffrently.
Foo. There went all my karma.
Why? It conforms to slashdot's bias. And was well written. I just happen to think it was also wrong. Now as to what happes to my karma...
P.S. you did forget to mention uLinux, the Linux that can run on non-MMU devices. I can see that being a big advantage in the embeded market. It's not something I would enjoy using, but still, it's a big deal if you can leave out a MMU and save $3 on a box that has a $50 price tag...
P.P.S. you'll note I didn't show anywhere I thought BSD was clearly better then Linux. That's because I'm not really sure there are any. There might be. There might not be. Or more to the point, each have their strengths, and weeknesses, and depending on what you need, one or the other might be better. You need to look close to decide, there is no easy answer (other then "not NT"...there, can I keep my karma? I bashed Microsoft)
[...]
Set-top boxes[...] In this sort of environment, the 'display anywhere' X protocol is just excess baggage and a more direct route to the screen makes a lot of sense, especially if you are a company intent on providing a cheap device for general home use and want to get maximum speed out of the hardware.
Actually that is where I most wish they would use X so I can have my non-embeded program display on my TV, or wrist watch, or car stereo's display, or PDA (assuming some sort of net connection). Witness the vast horde of folks wanting to do little more with the i-opener then turn it into an X terminal:-)
Of corse I can see where the company that wants to sell a dirt cheap box would rather have a cheaper device... or want to lock me into their application.
The code translation software optimizes on the fly. In particular, it perform unsafe optimizations and back off if a problem occurs. No static compiler can do that,; they always have to account for the worst case.
A static compiler can also do a "fast case" and "worst case" version of code. The advance load and check instructions on the IA64 are built for that sort of thing, and the speculatave load as well. The DEC/Compaq GEM compiler can do an alias and noalias version of a function and do an alias check on entry.
Existing CPUs don't have many features that encurage this, but it can definitly be done. It will bloat the code some, but if the common cases is common enough the extra i-cache traffic will be minimal.
Thus it really only handles one instance of X. I believe that for every graphical login you would have to have a copy of the XServer running... Very resource intensive!!!
Um, and the problem would be?
I havn't got a whole lot of Linux experiance, but I assume that just like any other modern Unix-like system it can swap out unused processes, so when you are not using your graphical enviroment the data area for that X server (Xvnc) will be paged out to disk, and the text (code) area will be shared by all the other running copies.
More over, if they want you to be able to have graphical desktops that save state, how else would it be done? ICCCM and XSM (or whatever the session managment was named after ICCCM's session managment was declared a failure) has been around for years and still doesn't work for everything (or really much of anything!). It has to be somewhere. If it can't be on the client, it has to be on the server.
You might be able to kludge something together, most of the parts are certainely there. But VNC is designed more for network control of a centralized server than allowing generic graphical X logins.
From VNC's web pages they say it was orignally designed for a ATM baised lightweight "Network Computer". In other words allowing X (windows/mac) graphical logins.
Also VNC *can* be very resource heavy on the server system, even w/o the overhead of one instance of X to login...which is killer if you are serving *lots*. Using a Java XServer has the advantage that it adds no more overhead than is minimally necessary (I mean, you have to run multiple instances of your WM/Desktop and Apps, but other than that).
The Java XServer is fairly "resource easy" on the central server. But it doesn't let you save state from session to session. It also deals with lack o' bandwidth in a very diffrent way from VNC. For example a Xserver without enough bandwidth scrolling a single xterm will scroll it slowly, and become unresponsave to the user. VNC will appear to skip chunks of the text (like seeing still-frames of a movie), but will remain fairly responsave to the mouse and keybord.
I run VNC (over SSH) on my home machine, and access it from work, from my windows box (it has the monitor, for my wife's convenence), from other places. It's pretty nice. I keep three sessions running (three Xvnc's).
If my only concern was resource use I would probbably put an X server on my other machines at home (well, not the palm pilot), and do it that way. But the "never ending X session" is an extreamly handy feature. I gladly pay the small price VNC forces from me. It ain't a bad choice here either.
It is the first product that AMD has developed that doesn't totally follow Intel's lead. The K5, K6 and Athlon were created to compete with equivalent Intel products: The 486, Pentium and Pentium Pro/II/III.
If we ignore AMD's many non-CPU products, there is still the AMD29k, a fine RISC CPU that had some great success in the printer market, and a few other embeded markets before it was discontinued.
Shortly after that the article says:
Intel has gone the "RISC-y" path while
The IA-64 is definitly not a RISC. It has a few similar features, like being a load-store archature, but it has a lot of unRISCy features. The instruction decode looks very very complex (for no good reason). The modulo-scheduled register file while having some resemblence to SPARCs register windows are really a whole diffrent beast (ironicly having more resemblence to the AMD29k's "local" registers!). It is chock full of out and out scheduling restrictions (not as in "do this and it is slow", but "you can't do that", "if you do this who knows what happens").
There are lots of intresting ideas in IA-64, many that may actually pan out. But calling it an "EPIC" rather then "RISC" isn't marketing speak, it really does have a lot of non-RISC attributes.
Yup. I was picking on Java. Python is almost nearly the perfect language, although Perl has an implicit advantage in having so many people and packages already developed.
Let's take a trip back in time to the Bad Old Perl Four days... perl has no modules, it does have includes, and there is a modest set of useful things allready written up for you to include. Python has modules, and pre-parsed token files, and thousands (well, 100s) of pre-written modules for useful things, most of which Perl doesn't.
(I had to learn a lot of Python to work on a Civ I clone written in Python and CLIPS, I'm pretty sure Python was chose rather then Perl because Python had usable X and Xt and Xaw modules. Perl had a little-known X lib, but it was little more then the X wire protocall, lower level then C's Xlib!)
Will python reach this level of adoption? Lets hope so.
I'm guessing not. After all Python was once ahead of Perl, and lost the lead. But who knows. After all Python is a pretty nice language.
If I were in charge of a MMRPG, I'd forget about selling the game or selling time, I'd just set up an ISP and tell people "to play game or games X you have to use our ISP."
That will piss-off any potential customers that have a faster-then-dialup connection (cable modem, DSL, ISDN, FracT1...). It will also piss-off anyone that signs up and then has more trubble with "your" ISP then their old ISP. It will also piss off anyone who bought another ISP serice to play another MMRPG that required it.
Face it, most people allready intrested in most MMRPGs allready have an internet connection, and most people arn't that excited about changing it!
The closest I think you could get is to find an ISP who will roll the price into their service (or do one of those "virtual ISP deals" where you look like an ISP, but someone else does all the work), offer "free" service to anyone using that ISP, and charge anyone else a "modest" fee.
I do find the other idea in this thread intresting. Have the monthly fee, and a free version of the game, maybe a download-only, or a CD in shrinkwrap. You could still charge for a box with a printed manual and goodies, but make it free for people to start playing and paying the $10/month.
Not only would a good game get more customers, the customers could try the game for a far lower investment!
That is true for a number of reasons though. Many ISPs didn't have trouble getting ISDN, the problem was the lack of standards. Unlike Europe and Canada, the US has no single ISDN standard, which makes uniformity and support more difficult than it needs to be.
Having worked at a national ISP at the time I would have to say lack of standards was not the big problem. Most telcos would let you pick which ISDN options to have on a line (there are 100s, maybe 1000s). If you order the line from the telco (as opposed to the customer showing up with a line allready) ISDN's "lack of standards" (really more of a lack of ability to throw out anything in the standard and to instead just enumerate all possable choices) was no big deal.
The two problems (as I remember them) were getting orderes filled (being quoted multi-month lead times, and then having them slip was not uncommon), and totally diffrent price plans across the country (it is hard for a nation wide ISP to have a nation wide price if the serice it is baised on is flat rate in Amaritech land, and per minute in NYNEX land). The ISDN PRIs (T1s) were even worse then the BRIs (2B+1D-channel 128Kbit home end).
Much like with digital wireless connectivity, our capitalism, although making for great advances in technology, screws the consumer a little bit, by creating a lack of standard.
I'm whole unconvinced that digital wireless in hte USA has been screwed by lack of standard so much as the licencing method used by the FCC. Find a socalist or comunist country that has a Metricomm-like service. While GSM is very nice, I like my SCH-3500 for datacomm far better then my Nokia-9000i. I don't feel screwed by CDMA. I do feel screwed by Sprint Spectrum, but that's a diffrent issue.
ISDN was a late '70s, early '80s technology. It wasn't aggressavly marketed, well, ever (by the telcos that is). It wasn't lighlty marketed until late in the '90s. It was very hard to buy in the early '90s (like it was hard for ISPs to buy it, and they were use to talking to telcos then).
The more intresting table would be for when T1s, T3s, fractonal T3s, OC1, OC3, OC12... were actually available from a telco. Not when they were "designed" but when they could be bought. Unfortunitly the closest I can come to putting a date on any of those numbers is "frac T3s in the late '80s", and I'm not even positave about that one.
Bandwidth has been growing a lot lately, but that's unsupprising, research into it has been better funded lately. An intresting issue is what you need to route (or even switch!) data moving that fast. Juniper has nice products, but this is a hell of a lot of bandwidth. Fortunitly (and unfortunitly) it is on a lot of diffrent colors, and you could optically split them and send them to diffrent boxes to route/switch... but that only buys you so much, and it costs a lot too.
Let's face it - for a large commecial project, getting all those makefiles and dependencies right is a pain.
Yes it is. On the other hand dealing with inflexable make replacments in large or small enviroments is also a pain.
For example in my current "big" project I have ".t" files that are written in a language a perl script turns into.l++ files, which lex turns into.cc files. Make came with a built in rule to do the.l++ to.cc step, but I provided the.t to.l++ rule. If make hadn't let me do that I would have to run something else before each make, worse yet before each of some kinds of makes, but not others.
Example#2, in a recent "small" project I did to learn Java I wanted a yacc and lex like replacment. I found a few, but then I discovered neither of the IDEs I hade bought (CodeWarrier for Java, which was mostly crap, and Symentatec Visual Mumble-Mumble Java/Cafe/something which would be cool if it didn't crash a lot) support turning ".cup" files into ".java" files. CodeWarrier at least has a make I can decipher, but it seems to re-write that file and have no provisions for perminent changes. The tech support was unhelpful. Symentec didn't appear to have even that much. Again tech support was unhelpful. Neither integrated enviroments seemed to let me "integrate" anything else into them (be it a pre-parser, or a more vi like editor).
Eventually I stopped using the windows IDE and started using command line Unix tools, despite the fact that they were far slower. Despite the fact that the debugger Sun's JDK came with was really really primitave (GUI debuggers have some really nice advantages). The flexability of the enviroment was much better. My mussle memory (editor afinity) could be catered too. It didn't blow up every few hours, and damamge the OS.
All that said, I'm happy that borland is bringing this product to Linux. Some people will like what it provides more then the flexability of a tradtional Unix dev enviroment. Plus there is a lot of software written in it's language that can now be ported to Linux, some with very little effort. I just may have no dirrect use for it. (then again I may -- I'm a language junkie, and it's almost time to learn a new one...)
An Internet old-timer (he was in his *gasp* 50s) once told me that computer industry trade shows were good for only one thing: forcing companies to release products on time. Given the OSS idea of releasing early and often, do Linux trade shows serve this same purpose?
Trade shows have a few nice qualitys:
You get to see people and talk to them, rather then only being able to read them.
You have an "excuse" to focus on reading tech. papers for a few days, and not focusing on other immediate aspects of work.
If your work pays, it's almost a free vacation with payed meals:-)
If you have a good idea for a change it is sometimes far easyer to changes someone's mind in person (where you can see facial expreassions and change your "argument"'s focus)
While good questions get asked on email lists, some people with good questions don't participate thare. A confrence is a good place to hear their questions.
It's your chance to take your favroite OSS author out for dinner, or drinks (I'm not implying romance here)
OSS releases software early and often (idealy at least), but it has a lack of focus on papers, and other explanations. A confrence has some focus on tutorials, and paper presentations. So it does push those things to be "finished up".
Speaking of tutorials, um, there are tutorials. Sometimes they are fantastically useful in getting enough knolage about something to let you go back on your own and survive on the meger documentation that it comes with;-)
And did I mention the papers? Usenix has some really nice papers. The papers on the Freenix track arn't allways so good (many are just an abstract or slides), but they were better last year then the year before. So let's hope they keep improving.
I have never been to one, so I'm a bit curious...
They are fun. They are useful. If my company didn't pay, I would probbably pay to send myself to Usenix. At least if I could find a way to keep my wife from killing me. Damm, allways a catch.
If you have never been, try to get to one. Try to find one that is technical enough for you (Usenix's genneral confrence is quite technical; Comdex isn't very technical at all). You might want to avoid ones that are more technical then you want -- you don't want to be bored, and you don't want to be afarid to ask questions at the Q and A. Your best bet is to try to get the procedings from the previous year and see if the papers are intresting. Also look at the tutorials (if you can afford them) and see which shows have ones that intrest you (or your employer if they will pay). In my opnion deciding on which confrence to go to because of who the keynote speaker is, is, well, lame. After all the keynote is only 30 to 90 minutes of a several day event. On the other hand the keynote speaker makes a great tiebreaker. Then again, so does location.
You should have no trouble at all with already ported Linux apps. For example try this [netscape example]
For me that didn't quite work (under FreeBSD 3.4). I still have to set SOCKS_NS to my local host address. I poked around in the linux/etc, but it seemed to be set to do dns correctly. I guess I need more Linux sysadmin knolage to make all the emulated-linux stuff work right.
I guess I'll know if I still need it under 4.0 this weekend...
100,000$ US would last for aprox 20 years, without any form of interest or savings program (also not taking into account inflation), at most Canadian universities assuming 8,000$ Canadian is spent per year (average residence + fees + food + "small" disposably budget). Why get a masters from MIT when you can get a Ph.D in several things from the U of C?:-)
US$100,000 is far more then is needed in many US universities. In 1992 a semester at the University of Maryland (for Maryland residents) cost under $2,000. I don't know what the current prices for state-subsidised universities is, but it isn't unreasonable to expect the price has gone up a lot, but I doubt it is all that diffrent from the CA prices.
On the other hand many of the top Universities are not public funded (many are), the US budget is irrelevent to them. The privately funded Universities are expensave to go to because they are expensave to run. The continue to exist because some of the people with money to spend on their children's (or their own, or others') education thinks they are worth it. Doesn't CA have private Universities? Or are they all state-subsidised?
The article says the thing has "Full AGP 2X/4X device with multi-threaded bus mastering and AGP texturing", but never talked about "multi-threaded bus mastering". I had no idea either, and was kinda dissapointed that they explained bump mapping with 3 pages and 4 pictures, but didn't say anything about this at all.
After poking around on matrox's site, I found only a breif PDF document. As far as I can tell it means the G400 can be told to DMA a vetrex list, command list, and textures, and stuff, and the G400 will decide which needs to be feteced next, and how much of it. Sounds useful, but I donno if it really is.
Another possability is that radio emissions from more advanced technologies resembles noise more and more as they get incresingly advanced.
Look at morse code, then AM radio, AM radio looks just like a frequency shifted verison of the voice/sound pattern (because it is). FM radio is a good deal harder to figure out from looking at it what it is trying to say, but it is obvious that something is there. CDMA, I can't find CDMA on a specrum analiser, and I even know where it lives on the frequency band!
The next thing you know, we'll be denying the AIs the right to speculate on the stock market,[...]
We allready do. When the market goes down (and maybe up) "too fast" some types of trading are susspended. I think the first to be traded are mathmatically derived trading orders (i.e. the only thing we have that approximates AIs). Orders from real people (be they E*Trade at-home-daytraders, or the manager of a $4bln mutual fund) are allowed to go through. At least unless the market keeps doing the Bad Thing, in which case there is a short cooling off period (no trades accepted). At least that's the storey on hte NYSE, I would assume the NASDAQ has the same sort of deal.
Oh, and this info is about two years old, so don't go betting your house on it.
Excuse me? Bottom up design isn't a magic wand. If you don't understand the problem, no design, whether bottom or top down will work. If you don't have a deep understanding of what you want to simulate - you won't simulate it
No, but Genetic Programming is. Sort of. It can, given enough time, work out a rough program (very rough) that can solve a problem the programmer can't descibe an algorithm for.
"All" you need to provide is a fitness function that indicates how close the answer is (say 0.0 for not at all, and 1.0 for perfect), primitaves to be used to solve the problem (turn left, move forward, pick-up-food...) and a genetic cross over function (which is almost trivial, they can normally be reused from one GA to another).
And a shitload of time.
If you look at some of the GA derived programs for simple problems like an ant colony collecting food, they suck. Full of dead code (like "if (next to water) then if (not next to water) then 100-lines-of-never-reached-code-here"). But they work. At least for the sample problem set, and problems that are similar.
If you look at some of the GA FPGA programs you will see designs with far fewer transistors then a person would have used. But they also only work within (roughly) the tempature range used during the GA test runs. And they have circuits that don't appear to do anything, but if you remove them the design stops working (capatictance issues I expect), and other crap a humon designer would avoid like the plague.
In both cases it took a really long time for the GA to find the winning "program". GA uses the same sort of techniques that it is beleved "mother nature" uses to "design" plants and animals. In other words lots of trials, a handfull of mutations, some sexual reproduction (or asexual, but that is less effecent), culling the less efficent, and time. The results are somewhat more comprehensable to man, but only (in my opnion) because the fitness functions is so much simpler. The real one changes over time.
GA is a magic wand that may give us AIs. But I don't think it will give us ones we can understand the working of any better then the natural intelegences we allready have to study.
On the plus side, it can give us some kick-ass smart simulated ants:-)
This is the problem with Asimov's "three laws of robotics". In fact, in one of his stories (I forget which), he points it out at the end when basically two of the robots (while switched off!) decide they are superior or "more human" than the organic humans for various reasons. So even though they are still bound by the three laws in this case, the definition of "human" has changed -- to the robot's advantage. The implications of this are not worked out though.
Read the non-Asamov Foundation books. I think the Brin one goes into this in more depth.
A well planned transportation policy should get rid of this subsidized personal transportation policy and make people pay the real cost for the use of cars and trucks over public roadways.
Subsidized? You mean by the gas tax, and personal property tax on cars, and title and tag fees on cars, and (in some places) road tolls, and ticket revnues?
Or do you mean the Federal Highway "assistance" that the federal goverment likes to use to get "assistance" on unrelated issues from the states? (lots of funds are conditonal on parcipation in various drug programs, or other non-road related issues)
The reason why public transportation systems have been so neglected is mainly a question of bad pricing regulation. You don't need to explicitly pay anything to drive on public roads and streets.
Thats one thery. Another is people don't like standing in the cold and rain to catch a bus. Another is that the busses and trains don't run all the time (i.e. people are afarid if they rely on the bus that if they have to stay late at work they won't be able to get home). As a former rider of busses and trains, I can say those were big downsides for me.
People want to have a personal computer on their desks, but mainframes are still the best solution to many tasks.
Intresting choice of analigy, since I bet the ratio of public transit systems to private cars and of mainframes to personal computers are allready pretty similar, yet you are arguing for more public transit (and fewer cars).
What's my answer? I don't really have one. I wouldn't be opposed to more directl linking the costs of cars to their operation, through say even higher fuel taxes, but only if the existing monies allready used to pay for the roads are given back. I'm not intrested in anything that makes cars more expensave without making something else less expensave.
I would also like to reduce the "zero emissions vechile" requirments a bit. Zero emissions really only has an eletric solution, and only because electric power lets you cheat by having the poultion gennerated elsewhere (nasty coal plants). Having a very low emissions standard would get you things that actually polute as little as an EV, and may have better range, or a better ride, or actually not be so dammed expensave.
But most of all, I would like to reduce goverment involvment, because they seem to fuck up everything the touch. Look at our public eductaion system and tell me otherwise. Or the highly regulated helthcare industry. Or compair the still regulated phone componies with the internet componies (or the current not-as-regulated phone componies with the highly regulated Bell System of the 1970s).
I know that alot of people here think the EULAs are junk, but in reality some of them are legitimate. Although I think this is very cool, isn't this a blatant misuse of their device. I assume that there is somewhere where they say you can't disassemble them, and in this case, where they are selling them at a loss, they have a legitimate reason to request this.
I don't think they did, and the EULA wouldn't be needed. All they need is a cell-phone like contract when you buy that you sign up for X months of their $20 service, or pay a sliding termination fee. Which as far as I know they don't (yet) require.
Those contracts are enforcable (since you sign them when you buy the product, not "click" them after). And in my opnion they are also fair since you know the terms before you get home. That's the thing I hate about the EULA. You can buy a product and when you get home discover that there are all sorts of restrictions on it. I want to know what I'm buying before I put my money down. I don't want to get home and then decide I have to drive back to the damm store and return it.
The downside (from netpliance's point of view) is people don't like to make that kind of commitment. Just look at how many more people sign up for the no/low commit moble phones now vs. about five years ago when there were no low commit (let alone no commit) phone plans!
On a second note, what are the terms of their contract. Assuming you are buying the product, and not just on an indefinate lease, how long are you required to use their internet service before terminating the contract?
From what I have read here, there is none. Even if there was one this would be nice because it means there would be a use for this $99 box even if netpliance went bankrupt (and face it, this kind of market is really rough, they have to compete with $0 PCs offering the same kind of deal, but with a 2 to 4 year ISP commitment).
re: chip competition. doesn't seem to have worked even though you'd think it would be in their best interest not to be trailing the pack.
It doesn't seem to have put them in first, second, or even 3rd place in CPU speed. On the other hand maybe without it they would be dead, and dead last. After all Sun was never focused on CPU design, they only did the first SPARC in house. DEC had been good at it over twice as long as Sun had been in existance when that stratagey was picked. Sun had no fab plants then either.
Then again maybe if Sun had decided to build a pool of talent and do it in house the SPARC could be at the top of the SPECfp list, not the Alpha (or does the 1Ghz K7 manage to beat the 700Mhz Alpha? I doubt it, the Alpha had a 3x SPECfp lead last I saw).
I don't think any of these companies had a chip that wowed folks at introduction (does this mean there's something wrong with the basic processor architecture that constrains speed so that none could succeed?).
The first SPARC, the 4/110 and 4/220 were three times faster then machines costing five times as much. The were a revolution. The didn't wow folks, they stright out floored them. At least the ones that didn't think it was a lie. They made no impact on the PC market since they were $10,000 machines.
The first really popular SPARC the one in hte SparcStation1 was again so much bloddy faster then anything anyone else had that DEC had to drop their plans to design a RISC CPU in-house and start the fastest workstation design-to-market project ever done (I think it was a little under a year, or a little over, I forget which).
When DEC finally brught their MIPS baised machines to market and edged out past the SPARC Sun brought the SPARCStation 1+ out (as an in-line upgrade -- existing SS1 orders were shipped the SS1+ at the same cost!) forcing DEC to drop it's brand new DS2000 because it was laughable next to the 1+ (or maybe this was the 2, I forget).
It was only after DEC managed to bring the Alpha out that they managed to beat the SPARC, and keep beating it for the rest of the decade. Not bad for a little upstart workstation peddling "snake oil" and hoping to one day "piss with the big dogs".
The SuperSPARC was impressave, but not ground breaking. The MicroSPARC was pretty wowing, if you were intrested in low cost CPUs (it was very cheap from the very start -- and not too slow). The Ultra1 and Ultra2 were not awe inspireing. The SPARC-V9-US3 is not wowing in terms of clock rate, but in terms of L1 and L2 load to use latency they are indeed wowing. But it is Mhz that makes the headlines. Even if SPECint/SPECfp would be a better set of numbers to chase.
Too bad CPUs cost so much to make, it would be intresting to see what would happen if a compony designed an extreamly long pipelined CPU with a fantastically fast clock that wasn't really all that fast (the long pipeline would make a fast clock "easy", and at the same time make it impossable for the CPU to actually be fast without monster good load bypassing and branch prediction). Would it sell great because it's clock is 2x to 3x to 4x as fast as everyone else's, or would it flop because it would be slow as a dog on any real code?
And wasn't it 5 or so years ago Zander told anyone selling Suns they'd forfeit their contract if they stocked things like Solbournes(sp?)?
Probbably more then five, I think Solborne was only around from '91 to '94. The Solborne was a competing SPARC baised system, not a new SPARC CPU Sun could put in their box. Worse yet it did multi-CPU suport much better then SunOS did (Solaris wasn't out at the time).
It was probbably a dumb move (long term), but it wasn't quashing a rivel CPU. they even used the same CPUs most of the time.
re: TPC (?). Last I looked at http://www.tpc.org Compaq and IBM solutions had it all over the big Suns (in the top 10 performance leaders). Granted the best Sun number shipped late last year and the IBM & Compaq shipments come later this year (so Sun may be able to retake the lead before they ship).
I assume that is true, but I don't know for sure. Also while the Compaq's are priced similar to Suns (I think) the IBMs cost a lot more. Then again they have a better rep for reliability.
Though it does look like Compaq can just keep on adding machines (rather than telling the customer "sorry, your problem just got too big".) Seems they get linear scalability going from 32 to 64 to 96 processors.
I doubt it keeps scaling linerally after that -- unless they had all 10 top 10 spots they would have kept showing better systems. The PR coup of holding the top 10 spots (or top 5!) would make it worth it. Even for an expensave benchmark like TPC-C.
[lots of other Big Compaq better then Big Sun quotes]
I have no idea. We have strayed far from my area of knolage. I will say Alpha kicks some serious ass, and I'm not supprised you can make nice systems from them. But it is really a market where I don't buy machines, I don't evaluate them, and I don't really understand the needs of. I'm a "small server" guy myself. If I can't lift it, I probbably don't run anything on it. (note, I can lift systems one at a time and still get a rack full of small servers).
re: reliability. The big Dells we have have not had a cpu die that I know of, but I know our big UE has had multiple processors replaced, and NICs die, I think. Ok, it is a little older (but I don't think I've ever seen the even older pentium Pro 200s fail). What's your experience with the Sparcs? I suspect they run too hot for their cooling (or need more filter maintenance, or they are really serious about their humidity requirement - so the air is not too dry).
I havn't had a CPU or NIC on the SPARCs go bad yet (I have had a DOA or two shipped to me). I have had a DEC NIC go very bad (caused the machine not to boot), one of hte DE-100s. It happened to be in my home machine though, so heat/dust/humidy wasn't the same. All my DECs are PCs. Most of them ageing. I've had drives go bad on both (many more on the DECs, but that is the fault of the HP SporeStore drives). The DECs lock up randomly sometimes (like once a month per 100 machines), the SPARCs get an ECC'ed bus fault less then once a year per 100 machines, and the OS (not solaris, same OS on the PC and SPARCs) re-try code for that didn't work last time it happened (it has happened maybe three times). Most of the SPARCs are newer, but some are quite old SPARC20's with 3rd party ROSS HyperSPARC modules.
The PCs are all in a nice machine room. Some of the SPARCs are in a not-so-nice Telco-co-lo (well, Ok, it's pretty nice too). I would never do that with a PC. We have done "hands off" OS upgrades on the SPARCs (one of the benifits of being a small server guy is I can send all the load to machines B and C when i take A down for an upgrade). Literally we schedule someone to put the new OS CD in the SPARC, and then at out lesure we schedule the upgrde and do it from halfway across the USA with nobody at the facility.
Christensen in his Innovator's Dilemma implies that all the "ilities" follow investment which follows volume times price point at a given interface. So the mass market stuff has got to have better reliability (else it would not be mass market).. (and the maintenance fees would be outrageous - and they're not). where appliances are the example. 10s-100s of millions of anything have to be more reliable 10,000s of something (else there are not enough phones in Baltimore to answer the calls).
I beleve that as a genneral rule, but there are niche markets where reliability is the goal, not price. I totally expect a IBM390 to be far more reliable then the best x86 machine built. Even if part of that is only that the 390 is designed to detect the error, and let you replace the part with no intrruption of service (or minimal).
Also the SPARC and Alpha and mainframe buyers take much more time on the phone. They won't hang up until the problem is solved. PC buyers have been conditioned to take various forms of "you'll have to upgrade", "that isn't a supported configuration", and "oh, that's Microsoft's fault". They don't insist you give a root cause failure analisis.
I do belve he is right about the ford Mustang being less prone to brakage then a Lotus, or Ferrari.
This has been a long reply. Hoe someone reads it:-)
Oh come now. At least part of the reason that the Dreamcast has an MMU is that there is no SH-4 part shipping without one. Hitachi is targeting SH-4 to WinCE with or without Sega. You buy an SH4, you get an MMU.
Is it that hard to beleve that the SH-4 was chosen so the Sega could run WinCE? Or that if Sega had not wanted the MMU they could have had a respin of the SH-4 with no MMU (the graphics chip has more transistors if you ignore the cache and is Dreamcast specific, it is a PowerVR with a new Bus and a few other small tweeks)? The sound chip is a ARM7 plus DSP extensions and a few I/O ports (and I assume DACs).
Interestingly it doesn't specifically state that EE has an MMU, but it's rather hard to believe that Sony would ship PS2 without an MMU - since we're being led to believe that PS2 is supposed to be much more than just a game platform anyway.
We have the same facts. Nobody said it has an MMU. Nobody said it didn't. It is in a market where MMUs normally arn't. It was baised on a CPU that has one (but embeded MIPS CPUs have skiped them before). Sony claims they are going for a wider market.
We merely disagree on whether Sony did "the right thing" and put a MMU in it. Personally I think it would be nice if it had one. I also think odds are aginst it.
Sounds like Sun needs some competition in their sparc suppliers (and/or design teams). Especially if they want to move folks to mostly interpreted code in servers.
Sun has some. TI makes the UltraSPARC. Fujutsi (or Samsung?) is working on the HAL SPARC V9 (and has been for some time). In the past Cypress, Ross, Fujutsi, and Samsung, and Mekio have all made SPARC CPUs. Sun publishes the SPARC ABI and ISA, and promotes compatation. They even publish the bus specs.
The problem is componies don't see as much profit in that design space as in x86 compatables. There is a lot of money to be made there, but if Sun doesn't pick you to make CPUs for them, you end up in SPARC clones, or 3rd party CPU modules, and there just isn't the same kind of money there.
And Intel & AMD's IO seems to be coming along, including memory bandwidth (> Sun's IBM's). Especially when you divide the number of processors into the memory subsystem bandwidth. And Sun is now says they are following Intel's lead on next generation IO?
Sun switching from SBus to PCI isn't the same as Sun following Intel on I/O. Sun still does their own memory systems (well low end boxes use PC memory because that is the only way to get prices even remotely close to PCs).
Morover PCs almost allways have one PCI bus, plus one or more bridged PCI busses. The bandwidth from the CPU to any pair of PCI devices is limited to half the PCI bandwidth (half for one, half for the other, and in reality some switching cost). Sun's high end machines (even their midrange) have multiple independent PCI buses, so you can push a Ultra160 SCSI at 160Mbytes/sec on one PCI bus, and not interfere with bandwidth on another PCI bus. The Sun SPARC4500 can have 4 diffrent sets of PCI busses (the 4500 is also one of the last SBus machines, what it really takes is up to four backplane bords which can have memory and CPUs and/or PCI and SBus slots; each backplane bord communicates over a very high speed bus the "FHB")
PCI (esp. the 66Mhz 64bit kind found on many Suns) has enough bandwidth to handle most all perhrials, and is cheep. So it is a fine bus for most things. Why is Sun wrong to use it?
Why are the Sun boxes still popular for non-scientific work (perhaps even scientific)? There are lots of faster Unix boxes (and it sounds like even Linux on PCs runs rings around equivalent systems - given the same number of processors and memory and disks). It is hard to find benchmarks for comparison (can't blame them).
At the low end I susspect:
Reliability. The things are way more reliable then PC servers. The hardware that is. (well I donno about Suns UltraCheep boxes, I have no Ultra5/10 experiance)
Easy of assembly. Ever used Suns SCA drives? Don't you wish PCs had them? No messing with cables, pull the lever up toss the old drive, put the new one down there, push the lever, drive installed. No cable mess. No mounting screws.
Name brand
"We have other Suns"
Lots of software
At the high end
I don't care that you can get 4 800Mhz Intels in one box, i have 40 400Mhz CPUs! Ha! Ha! Ha-Ha!
Have you seen our TPC-C numbers?
If you want a big Oracle system, well there is really only one place to go (and have you seen our TPC-C numbers?)
Did you notice we are slowly becoming mainframes (and have you seen our TPC-C numbers)?
Or at least that is my guess, I don't buy big Sun boxes. Just the medimum ones.
Even if I think I can guess the address Google is going to list the real site first. After all I would not want to wind up somewhere like www.whitehouse.com by accident.
Since you have added a link to whitehouse.com from a highly rated site (slashdot) you are slowly making google think you want the wrong answer here...
Incidentally (slightly OT) speaking of people tracking what you are doing and all that, what is the scoop with @HOME's proxy servers? The only reason that I can see for them wanting you to use their proxy server is to track users. And boy do they go out of the way to force people to use their proxy server!
They might want the proxy to track users, but only as a very secondary reason. The real reason is @Home has limited bandwidth to "real" national backbone ISPs, and using a local cache will help conserve that expensave (to them) resource. If they put caches close enough to the users it also reduces the load on whatever backbone they have built themselves.
Slashdot Mirror
And BSD is divided into a kernel (made of descrete components), and a user land made of descrete components like the C library, various shells, command line utilities, etc., which can be easily replaced with other things.
Try again. Neither Linux nor BSD has an advantage in this area.
Well, yes FreeBSD at least provides a strong incentave to use what is provided, namely making it dirt simple to use that stuff. It doesn't make it any harder to use non-ports stuff then any other Unixlike OS. You can even use the FreeBSD package manager (which allows dependnecy tracking, and easy uninstall) with non-ports software. Of corse if you did, it would be a tiny step to make it "ports software" (namely a few text files).
But I have installed a lot of non-ports stuff on my FreeBSD box (mostly snapshots of newer-the-ports stuff). I don't see how it diffres from installing a "too-new-to-be-RPMed" package in Red Hat.
I would say no advantage between Linux or BSD in this area.
Yes, unless you master the mystical "rm" command, you will still have the tarballs after you "make clean" (rm /usr/ports/distfiles/* works pretty good). I do wonder why there isn't a cron job to clean old files out of /usr/ports/distfiles, but this is definitly someting almost anyone ought to be able to do on their own if they wish.
I think the general thery under BSD would be to compile a kernel, libc, and the other tools you need, put them in in a binary distrubution (see the "mfsroot" tools). Even without the package manager, if it is offensave or useless to you.
For examples look at PicoBSD, the 1.44MB distribution, or maybe at the BSD in Juniper's M-series $100k+ routers, or at the BSD in Ascend's GRF routers. Or IBM's ePIPE, or Whissle's InterJet. Or, hell, the X-Terminals I built in 1992.
Again, Linux and BSD are pretty much the same in this regard.
I don't see any reason why BSD is less "open source". It is "less GPL", and arguments can be made about whether that is good or bad. But it fits ESR's Open source Definition. I've had patches accepted by various BSD groups. I've had them rejected as well, and a better fix was taken in their place. I havn't made any Linux patches, but I hope (and expect!) the result would be the same, my well-written patches would be accepted, and my flimsy half-baked hacks would be rejected, and maybe done better by someone else.
As for the forking, I remain unconvinced that Red Hat, SUSE, Debian, Slackware, Corel, Mandrake, Trustix, Storm and Yellow Dog are really signifigantly more similar then FreeBSD, OpenBSD, and NetBSD. Yes, all the linuxes are a kernel that Linux blessed, plus (sometimes) patches, and diffrent config options. But the userlands are all diffrent. Just like the BSD userlands. And as far as portability goes that is about as bad. Which is to say, a slightly-more-then-minor problem for source shipped programs, but not a major huge super big showstopper problem (in either BSD or Linux!)
Even if convinced, I'm not sure it would be a wholey good thing. If userland devirsity is a good thing, why is not a little kernel diversity? I really enjoy having multi-CPU support in FreeBSD. On the other hand, when I want a really secure system, I appreciate Theo's stance that the multi-CPU stuff hasn't been around long enough to be sure there are no security-related race conditions in it.
Here we have the first non-tie. BSD is better if you are intrested in deversity at all levels. Linux is better if you want basically the same kernel everwhere, but don't care about the userland being quite so similar.
Well, Linux does have Linus to keep everyone roughly on track. And that is a major big deal. BSD has nobody with the same leadership skills, who has stepped into the same sort of role.
On the other hand I wouldn't exactly say BSD has been left in the dust so far, and Linux has been around, what, nearly 10 years now?
Linux has gotten some really cool stuff recently (XFS, Riserfs being the most intresting), but BSD hasn't exactly been sitting still (look at the FFS soft update code, and the work-in-progress version of FFS that can do NetApp style snapshots, and live-filesystem-fscks). Linux seems to have gotten quite a leg up in fine-grained SMP, but with the recent Walnet Creak/FreeBSD/BSDI annoncment, I expect BSD can "catch up". After all Paul Borman allready did fine grain locking in Cray's TCP/IP stack, how hard could doing it twice be? :-)
My summary for this one would be "answer unclear, try agian next year". But I accept diffrent peple could judge this diffrently.
Why? It conforms to slashdot's bias. And was well written. I just happen to think it was also wrong. Now as to what happes to my karma...
P.S. you did forget to mention uLinux, the Linux that can run on non-MMU devices. I can see that being a big advantage in the embeded market. It's not something I would enjoy using, but still, it's a big deal if you can leave out a MMU and save $3 on a box that has a $50 price tag...
P.P.S. you'll note I didn't show anywhere I thought BSD was clearly better then Linux. That's because I'm not really sure there are any. There might be. There might not be. Or more to the point, each have their strengths, and weeknesses, and depending on what you need, one or the other might be better. You need to look close to decide, there is no easy answer (other then "not NT"...there, can I keep my karma? I bashed Microsoft)
Actually that is where I most wish they would use X so I can have my non-embeded program display on my TV, or wrist watch, or car stereo's display, or PDA (assuming some sort of net connection). Witness the vast horde of folks wanting to do little more with the i-opener then turn it into an X terminal :-)
Of corse I can see where the company that wants to sell a dirt cheap box would rather have a cheaper device... or want to lock me into their application.
A static compiler can also do a "fast case" and "worst case" version of code. The advance load and check instructions on the IA64 are built for that sort of thing, and the speculatave load as well. The DEC/Compaq GEM compiler can do an alias and noalias version of a function and do an alias check on entry.
Existing CPUs don't have many features that encurage this, but it can definitly be done. It will bloat the code some, but if the common cases is common enough the extra i-cache traffic will be minimal.
Um, and the problem would be?
I havn't got a whole lot of Linux experiance, but I assume that just like any other modern Unix-like system it can swap out unused processes, so when you are not using your graphical enviroment the data area for that X server (Xvnc) will be paged out to disk, and the text (code) area will be shared by all the other running copies.
More over, if they want you to be able to have graphical desktops that save state, how else would it be done? ICCCM and XSM (or whatever the session managment was named after ICCCM's session managment was declared a failure) has been around for years and still doesn't work for everything (or really much of anything!). It has to be somewhere. If it can't be on the client, it has to be on the server.
From VNC's web pages they say it was orignally designed for a ATM baised lightweight "Network Computer". In other words allowing X (windows/mac) graphical logins.
The Java XServer is fairly "resource easy" on the central server. But it doesn't let you save state from session to session. It also deals with lack o' bandwidth in a very diffrent way from VNC. For example a Xserver without enough bandwidth scrolling a single xterm will scroll it slowly, and become unresponsave to the user. VNC will appear to skip chunks of the text (like seeing still-frames of a movie), but will remain fairly responsave to the mouse and keybord.
I run VNC (over SSH) on my home machine, and access it from work, from my windows box (it has the monitor, for my wife's convenence), from other places. It's pretty nice. I keep three sessions running (three Xvnc's).
If my only concern was resource use I would probbably put an X server on my other machines at home (well, not the palm pilot), and do it that way. But the "never ending X session" is an extreamly handy feature. I gladly pay the small price VNC forces from me. It ain't a bad choice here either.
First the article says
If we ignore AMD's many non-CPU products, there is still the AMD29k, a fine RISC CPU that had some great success in the printer market, and a few other embeded markets before it was discontinued.
Shortly after that the article says:
The IA-64 is definitly not a RISC. It has a few similar features, like being a load-store archature, but it has a lot of unRISCy features. The instruction decode looks very very complex (for no good reason). The modulo-scheduled register file while having some resemblence to SPARCs register windows are really a whole diffrent beast (ironicly having more resemblence to the AMD29k's "local" registers!). It is chock full of out and out scheduling restrictions (not as in "do this and it is slow", but "you can't do that", "if you do this who knows what happens").
There are lots of intresting ideas in IA-64, many that may actually pan out. But calling it an "EPIC" rather then "RISC" isn't marketing speak, it really does have a lot of non-RISC attributes.
Let's take a trip back in time to the Bad Old Perl Four days... perl has no modules, it does have includes, and there is a modest set of useful things allready written up for you to include. Python has modules, and pre-parsed token files, and thousands (well, 100s) of pre-written modules for useful things, most of which Perl doesn't.
(I had to learn a lot of Python to work on a Civ I clone written in Python and CLIPS, I'm pretty sure Python was chose rather then Perl because Python had usable X and Xt and Xaw modules. Perl had a little-known X lib, but it was little more then the X wire protocall, lower level then C's Xlib!)
I'm guessing not. After all Python was once ahead of Perl, and lost the lead. But who knows. After all Python is a pretty nice language.
That will piss-off any potential customers that have a faster-then-dialup connection (cable modem, DSL, ISDN, FracT1...). It will also piss-off anyone that signs up and then has more trubble with "your" ISP then their old ISP. It will also piss off anyone who bought another ISP serice to play another MMRPG that required it.
Face it, most people allready intrested in most MMRPGs allready have an internet connection, and most people arn't that excited about changing it!
The closest I think you could get is to find an ISP who will roll the price into their service (or do one of those "virtual ISP deals" where you look like an ISP, but someone else does all the work), offer "free" service to anyone using that ISP, and charge anyone else a "modest" fee.
I do find the other idea in this thread intresting. Have the monthly fee, and a free version of the game, maybe a download-only, or a CD in shrinkwrap. You could still charge for a box with a printed manual and goodies, but make it free for people to start playing and paying the $10/month.
Not only would a good game get more customers, the customers could try the game for a far lower investment!
Having worked at a national ISP at the time I would have to say lack of standards was not the big problem. Most telcos would let you pick which ISDN options to have on a line (there are 100s, maybe 1000s). If you order the line from the telco (as opposed to the customer showing up with a line allready) ISDN's "lack of standards" (really more of a lack of ability to throw out anything in the standard and to instead just enumerate all possable choices) was no big deal.
The two problems (as I remember them) were getting orderes filled (being quoted multi-month lead times, and then having them slip was not uncommon), and totally diffrent price plans across the country (it is hard for a nation wide ISP to have a nation wide price if the serice it is baised on is flat rate in Amaritech land, and per minute in NYNEX land). The ISDN PRIs (T1s) were even worse then the BRIs (2B+1D-channel 128Kbit home end).
I'm whole unconvinced that digital wireless in hte USA has been screwed by lack of standard so much as the licencing method used by the FCC. Find a socalist or comunist country that has a Metricomm-like service. While GSM is very nice, I like my SCH-3500 for datacomm far better then my Nokia-9000i. I don't feel screwed by CDMA. I do feel screwed by Sprint Spectrum, but that's a diffrent issue.
Not supprising. I'm dislexic, half the time you can spell the same word three of four diffrent ways and I won't even notice.
ISDN was a late '70s, early '80s technology. It wasn't aggressavly marketed, well, ever (by the telcos that is). It wasn't lighlty marketed until late in the '90s. It was very hard to buy in the early '90s (like it was hard for ISPs to buy it, and they were use to talking to telcos then).
The more intresting table would be for when T1s, T3s, fractonal T3s, OC1, OC3, OC12... were actually available from a telco. Not when they were "designed" but when they could be bought. Unfortunitly the closest I can come to putting a date on any of those numbers is "frac T3s in the late '80s", and I'm not even positave about that one.
Bandwidth has been growing a lot lately, but that's unsupprising, research into it has been better funded lately. An intresting issue is what you need to route (or even switch!) data moving that fast. Juniper has nice products, but this is a hell of a lot of bandwidth. Fortunitly (and unfortunitly) it is on a lot of diffrent colors, and you could optically split them and send them to diffrent boxes to route/switch... but that only buys you so much, and it costs a lot too.
Yes it is. On the other hand dealing with inflexable make replacments in large or small enviroments is also a pain.
For example in my current "big" project I have ".t" files that are written in a language a perl script turns into .l++ files, which lex turns into .cc files. Make came with a built in rule to do the .l++ to .cc step, but I provided the .t to .l++ rule. If make hadn't let me do that I would have to run something else before each make, worse yet before each of some kinds of makes, but not others.
Example#2, in a recent "small" project I did to learn Java I wanted a yacc and lex like replacment. I found a few, but then I discovered neither of the IDEs I hade bought (CodeWarrier for Java, which was mostly crap, and Symentatec Visual Mumble-Mumble Java/Cafe/something which would be cool if it didn't crash a lot) support turning ".cup" files into ".java" files. CodeWarrier at least has a make I can decipher, but it seems to re-write that file and have no provisions for perminent changes. The tech support was unhelpful. Symentec didn't appear to have even that much. Again tech support was unhelpful. Neither integrated enviroments seemed to let me "integrate" anything else into them (be it a pre-parser, or a more vi like editor).
Eventually I stopped using the windows IDE and started using command line Unix tools, despite the fact that they were far slower. Despite the fact that the debugger Sun's JDK came with was really really primitave (GUI debuggers have some really nice advantages). The flexability of the enviroment was much better. My mussle memory (editor afinity) could be catered too. It didn't blow up every few hours, and damamge the OS.
All that said, I'm happy that borland is bringing this product to Linux. Some people will like what it provides more then the flexability of a tradtional Unix dev enviroment. Plus there is a lot of software written in it's language that can now be ported to Linux, some with very little effort. I just may have no dirrect use for it. (then again I may -- I'm a language junkie, and it's almost time to learn a new one...)
Trade shows have a few nice qualitys:
They are fun. They are useful. If my company didn't pay, I would probbably pay to send myself to Usenix. At least if I could find a way to keep my wife from killing me. Damm, allways a catch.
If you have never been, try to get to one. Try to find one that is technical enough for you (Usenix's genneral confrence is quite technical; Comdex isn't very technical at all). You might want to avoid ones that are more technical then you want -- you don't want to be bored, and you don't want to be afarid to ask questions at the Q and A. Your best bet is to try to get the procedings from the previous year and see if the papers are intresting. Also look at the tutorials (if you can afford them) and see which shows have ones that intrest you (or your employer if they will pay). In my opnion deciding on which confrence to go to because of who the keynote speaker is, is, well, lame. After all the keynote is only 30 to 90 minutes of a several day event. On the other hand the keynote speaker makes a great tiebreaker. Then again, so does location.
For me that didn't quite work (under FreeBSD 3.4). I still have to set SOCKS_NS to my local host address. I poked around in the linux /etc, but it seemed to be set to do dns correctly. I guess I need more Linux sysadmin knolage to make all the emulated-linux stuff work right.
I guess I'll know if I still need it under 4.0 this weekend...
US$100,000 is far more then is needed in many US universities. In 1992 a semester at the University of Maryland (for Maryland residents) cost under $2,000. I don't know what the current prices for state-subsidised universities is, but it isn't unreasonable to expect the price has gone up a lot, but I doubt it is all that diffrent from the CA prices.
On the other hand many of the top Universities are not public funded (many are), the US budget is irrelevent to them. The privately funded Universities are expensave to go to because they are expensave to run. The continue to exist because some of the people with money to spend on their children's (or their own, or others') education thinks they are worth it. Doesn't CA have private Universities? Or are they all state-subsidised?
The article says the thing has "Full AGP 2X/4X device with multi-threaded bus mastering and AGP texturing", but never talked about "multi-threaded bus mastering". I had no idea either, and was kinda dissapointed that they explained bump mapping with 3 pages and 4 pictures, but didn't say anything about this at all.
After poking around on matrox's site, I found only a breif PDF document. As far as I can tell it means the G400 can be told to DMA a vetrex list, command list, and textures, and stuff, and the G400 will decide which needs to be feteced next, and how much of it. Sounds useful, but I donno if it really is.
Another possability is that radio emissions from more advanced technologies resembles noise more and more as they get incresingly advanced.
Look at morse code, then AM radio, AM radio looks just like a frequency shifted verison of the voice/sound pattern (because it is). FM radio is a good deal harder to figure out from looking at it what it is trying to say, but it is obvious that something is there. CDMA, I can't find CDMA on a specrum analiser, and I even know where it lives on the frequency band!
We allready do. When the market goes down (and maybe up) "too fast" some types of trading are susspended. I think the first to be traded are mathmatically derived trading orders (i.e. the only thing we have that approximates AIs). Orders from real people (be they E*Trade at-home-daytraders, or the manager of a $4bln mutual fund) are allowed to go through. At least unless the market keeps doing the Bad Thing, in which case there is a short cooling off period (no trades accepted). At least that's the storey on hte NYSE, I would assume the NASDAQ has the same sort of deal.
Oh, and this info is about two years old, so don't go betting your house on it.
No, but Genetic Programming is. Sort of. It can, given enough time, work out a rough program (very rough) that can solve a problem the programmer can't descibe an algorithm for.
"All" you need to provide is a fitness function that indicates how close the answer is (say 0.0 for not at all, and 1.0 for perfect), primitaves to be used to solve the problem (turn left, move forward, pick-up-food...) and a genetic cross over function (which is almost trivial, they can normally be reused from one GA to another).
And a shitload of time.
If you look at some of the GA derived programs for simple problems like an ant colony collecting food, they suck. Full of dead code (like "if (next to water) then if (not next to water) then 100-lines-of-never-reached-code-here"). But they work. At least for the sample problem set, and problems that are similar.
If you look at some of the GA FPGA programs you will see designs with far fewer transistors then a person would have used. But they also only work within (roughly) the tempature range used during the GA test runs. And they have circuits that don't appear to do anything, but if you remove them the design stops working (capatictance issues I expect), and other crap a humon designer would avoid like the plague.
In both cases it took a really long time for the GA to find the winning "program". GA uses the same sort of techniques that it is beleved "mother nature" uses to "design" plants and animals. In other words lots of trials, a handfull of mutations, some sexual reproduction (or asexual, but that is less effecent), culling the less efficent, and time. The results are somewhat more comprehensable to man, but only (in my opnion) because the fitness functions is so much simpler. The real one changes over time.
GA is a magic wand that may give us AIs. But I don't think it will give us ones we can understand the working of any better then the natural intelegences we allready have to study.
On the plus side, it can give us some kick-ass smart simulated ants :-)
Read the non-Asamov Foundation books. I think the Brin one goes into this in more depth.
Subsidized? You mean by the gas tax, and personal property tax on cars, and title and tag fees on cars, and (in some places) road tolls, and ticket revnues?
Or do you mean the Federal Highway "assistance" that the federal goverment likes to use to get "assistance" on unrelated issues from the states? (lots of funds are conditonal on parcipation in various drug programs, or other non-road related issues)
Thats one thery. Another is people don't like standing in the cold and rain to catch a bus. Another is that the busses and trains don't run all the time (i.e. people are afarid if they rely on the bus that if they have to stay late at work they won't be able to get home). As a former rider of busses and trains, I can say those were big downsides for me.
Intresting choice of analigy, since I bet the ratio of public transit systems to private cars and of mainframes to personal computers are allready pretty similar, yet you are arguing for more public transit (and fewer cars).
What's my answer? I don't really have one. I wouldn't be opposed to more directl linking the costs of cars to their operation, through say even higher fuel taxes, but only if the existing monies allready used to pay for the roads are given back. I'm not intrested in anything that makes cars more expensave without making something else less expensave.
I would also like to reduce the "zero emissions vechile" requirments a bit. Zero emissions really only has an eletric solution, and only because electric power lets you cheat by having the poultion gennerated elsewhere (nasty coal plants). Having a very low emissions standard would get you things that actually polute as little as an EV, and may have better range, or a better ride, or actually not be so dammed expensave.
But most of all, I would like to reduce goverment involvment, because they seem to fuck up everything the touch. Look at our public eductaion system and tell me otherwise. Or the highly regulated helthcare industry. Or compair the still regulated phone componies with the internet componies (or the current not-as-regulated phone componies with the highly regulated Bell System of the 1970s).
I don't think they did, and the EULA wouldn't be needed. All they need is a cell-phone like contract when you buy that you sign up for X months of their $20 service, or pay a sliding termination fee. Which as far as I know they don't (yet) require.
Those contracts are enforcable (since you sign them when you buy the product, not "click" them after). And in my opnion they are also fair since you know the terms before you get home. That's the thing I hate about the EULA. You can buy a product and when you get home discover that there are all sorts of restrictions on it. I want to know what I'm buying before I put my money down. I don't want to get home and then decide I have to drive back to the damm store and return it.
The downside (from netpliance's point of view) is people don't like to make that kind of commitment. Just look at how many more people sign up for the no/low commit moble phones now vs. about five years ago when there were no low commit (let alone no commit) phone plans!
From what I have read here, there is none. Even if there was one this would be nice because it means there would be a use for this $99 box even if netpliance went bankrupt (and face it, this kind of market is really rough, they have to compete with $0 PCs offering the same kind of deal, but with a 2 to 4 year ISP commitment).
It doesn't seem to have put them in first, second, or even 3rd place in CPU speed. On the other hand maybe without it they would be dead, and dead last. After all Sun was never focused on CPU design, they only did the first SPARC in house. DEC had been good at it over twice as long as Sun had been in existance when that stratagey was picked. Sun had no fab plants then either.
Then again maybe if Sun had decided to build a pool of talent and do it in house the SPARC could be at the top of the SPECfp list, not the Alpha (or does the 1Ghz K7 manage to beat the 700Mhz Alpha? I doubt it, the Alpha had a 3x SPECfp lead last I saw).
The first SPARC, the 4/110 and 4/220 were three times faster then machines costing five times as much. The were a revolution. The didn't wow folks, they stright out floored them. At least the ones that didn't think it was a lie. They made no impact on the PC market since they were $10,000 machines.
The first really popular SPARC the one in hte SparcStation1 was again so much bloddy faster then anything anyone else had that DEC had to drop their plans to design a RISC CPU in-house and start the fastest workstation design-to-market project ever done (I think it was a little under a year, or a little over, I forget which).
When DEC finally brught their MIPS baised machines to market and edged out past the SPARC Sun brought the SPARCStation 1+ out (as an in-line upgrade -- existing SS1 orders were shipped the SS1+ at the same cost!) forcing DEC to drop it's brand new DS2000 because it was laughable next to the 1+ (or maybe this was the 2, I forget).
It was only after DEC managed to bring the Alpha out that they managed to beat the SPARC, and keep beating it for the rest of the decade. Not bad for a little upstart workstation peddling "snake oil" and hoping to one day "piss with the big dogs".
The SuperSPARC was impressave, but not ground breaking. The MicroSPARC was pretty wowing, if you were intrested in low cost CPUs (it was very cheap from the very start -- and not too slow). The Ultra1 and Ultra2 were not awe inspireing. The SPARC-V9-US3 is not wowing in terms of clock rate, but in terms of L1 and L2 load to use latency they are indeed wowing. But it is Mhz that makes the headlines. Even if SPECint/SPECfp would be a better set of numbers to chase.
Too bad CPUs cost so much to make, it would be intresting to see what would happen if a compony designed an extreamly long pipelined CPU with a fantastically fast clock that wasn't really all that fast (the long pipeline would make a fast clock "easy", and at the same time make it impossable for the CPU to actually be fast without monster good load bypassing and branch prediction). Would it sell great because it's clock is 2x to 3x to 4x as fast as everyone else's, or would it flop because it would be slow as a dog on any real code?
Probbably more then five, I think Solborne was only around from '91 to '94. The Solborne was a competing SPARC baised system, not a new SPARC CPU Sun could put in their box. Worse yet it did multi-CPU suport much better then SunOS did (Solaris wasn't out at the time).
It was probbably a dumb move (long term), but it wasn't quashing a rivel CPU. they even used the same CPUs most of the time.
I assume that is true, but I don't know for sure. Also while the Compaq's are priced similar to Suns (I think) the IBMs cost a lot more. Then again they have a better rep for reliability.
I doubt it keeps scaling linerally after that -- unless they had all 10 top 10 spots they would have kept showing better systems. The PR coup of holding the top 10 spots (or top 5!) would make it worth it. Even for an expensave benchmark like TPC-C.
I have no idea. We have strayed far from my area of knolage. I will say Alpha kicks some serious ass, and I'm not supprised you can make nice systems from them. But it is really a market where I don't buy machines, I don't evaluate them, and I don't really understand the needs of. I'm a "small server" guy myself. If I can't lift it, I probbably don't run anything on it. (note, I can lift systems one at a time and still get a rack full of small servers).
I havn't had a CPU or NIC on the SPARCs go bad yet (I have had a DOA or two shipped to me). I have had a DEC NIC go very bad (caused the machine not to boot), one of hte DE-100s. It happened to be in my home machine though, so heat/dust/humidy wasn't the same. All my DECs are PCs. Most of them ageing. I've had drives go bad on both (many more on the DECs, but that is the fault of the HP SporeStore drives). The DECs lock up randomly sometimes (like once a month per 100 machines), the SPARCs get an ECC'ed bus fault less then once a year per 100 machines, and the OS (not solaris, same OS on the PC and SPARCs) re-try code for that didn't work last time it happened (it has happened maybe three times). Most of the SPARCs are newer, but some are quite old SPARC20's with 3rd party ROSS HyperSPARC modules.
The PCs are all in a nice machine room. Some of the SPARCs are in a not-so-nice Telco-co-lo (well, Ok, it's pretty nice too). I would never do that with a PC. We have done "hands off" OS upgrades on the SPARCs (one of the benifits of being a small server guy is I can send all the load to machines B and C when i take A down for an upgrade). Literally we schedule someone to put the new OS CD in the SPARC, and then at out lesure we schedule the upgrde and do it from halfway across the USA with nobody at the facility.
I beleve that as a genneral rule, but there are niche markets where reliability is the goal, not price. I totally expect a IBM390 to be far more reliable then the best x86 machine built. Even if part of that is only that the 390 is designed to detect the error, and let you replace the part with no intrruption of service (or minimal).
Also the SPARC and Alpha and mainframe buyers take much more time on the phone. They won't hang up until the problem is solved. PC buyers have been conditioned to take various forms of "you'll have to upgrade", "that isn't a supported configuration", and "oh, that's Microsoft's fault". They don't insist you give a root cause failure analisis.
I do belve he is right about the ford Mustang being less prone to brakage then a Lotus, or Ferrari.
This has been a long reply. Hoe someone reads it :-)
Is it that hard to beleve that the SH-4 was chosen so the Sega could run WinCE? Or that if Sega had not wanted the MMU they could have had a respin of the SH-4 with no MMU (the graphics chip has more transistors if you ignore the cache and is Dreamcast specific, it is a PowerVR with a new Bus and a few other small tweeks)? The sound chip is a ARM7 plus DSP extensions and a few I/O ports (and I assume DACs).
We have the same facts. Nobody said it has an MMU. Nobody said it didn't. It is in a market where MMUs normally arn't. It was baised on a CPU that has one (but embeded MIPS CPUs have skiped them before). Sony claims they are going for a wider market.
We merely disagree on whether Sony did "the right thing" and put a MMU in it. Personally I think it would be nice if it had one. I also think odds are aginst it.
Sun has some. TI makes the UltraSPARC. Fujutsi (or Samsung?) is working on the HAL SPARC V9 (and has been for some time). In the past Cypress, Ross, Fujutsi, and Samsung, and Mekio have all made SPARC CPUs. Sun publishes the SPARC ABI and ISA, and promotes compatation. They even publish the bus specs.
The problem is componies don't see as much profit in that design space as in x86 compatables. There is a lot of money to be made there, but if Sun doesn't pick you to make CPUs for them, you end up in SPARC clones, or 3rd party CPU modules, and there just isn't the same kind of money there.
Sun switching from SBus to PCI isn't the same as Sun following Intel on I/O. Sun still does their own memory systems (well low end boxes use PC memory because that is the only way to get prices even remotely close to PCs).
Morover PCs almost allways have one PCI bus, plus one or more bridged PCI busses. The bandwidth from the CPU to any pair of PCI devices is limited to half the PCI bandwidth (half for one, half for the other, and in reality some switching cost). Sun's high end machines (even their midrange) have multiple independent PCI buses, so you can push a Ultra160 SCSI at 160Mbytes/sec on one PCI bus, and not interfere with bandwidth on another PCI bus. The Sun SPARC4500 can have 4 diffrent sets of PCI busses (the 4500 is also one of the last SBus machines, what it really takes is up to four backplane bords which can have memory and CPUs and/or PCI and SBus slots; each backplane bord communicates over a very high speed bus the "FHB")
PCI (esp. the 66Mhz 64bit kind found on many Suns) has enough bandwidth to handle most all perhrials, and is cheep. So it is a fine bus for most things. Why is Sun wrong to use it?
At the low end I susspect:
At the high end
Or at least that is my guess, I don't buy big Sun boxes. Just the medimum ones.
Since you have added a link to whitehouse.com from a highly rated site (slashdot) you are slowly making google think you want the wrong answer here...
They might want the proxy to track users, but only as a very secondary reason. The real reason is @Home has limited bandwidth to "real" national backbone ISPs, and using a local cache will help conserve that expensave (to them) resource. If they put caches close enough to the users it also reduces the load on whatever backbone they have built themselves.