Er, is there any problem with "all of them"? I've written a bunch of X apps, and none of them give a crap what window manager you run them under.
The rest of your argument looks more or less correct, look at all the complaints about Mozilla using GTK and not Qt, and then about it not really using GTK so much, and...
Of corse that didn't stop other Unix apps from making the choices (normally badly -- er, I mean normally Motif), and not get too many complaints...well, maybe a lot of complaints, but they are easy to brush off...mostly because I have no access to explosives, no, wait, I didn't say that out loud.
Cocoa apps are not X Window apps; they therefore cannot run UNIX systems for whom X Window is the only GUI
Cocoa is NeXTStep, right down to things being named NSfoo. Well, it is NeXTStep, plus some extra development, but not a ton of extra stuff (I guess they were busy doing other things).
So something that could run NeXTStep apps could run a subset of Cocoa apps. More importantly if the thing that ran NeXTStep apps were extended to do the extra things (like sheets, and adding "display PDF" (not too hard given Display PostScript)) it could probably run a lot of Cocoa stuff...
Where could we find something like that? Maybe GNUStep? I mean they have been working on it for a long time...
P.S. X Windows isn't a GUI. It's a rendering engine, and a method to get raw user input. Gtk and Qt are more like GUIs (technically they are just GUI toolkits, a big paper document called a User Interface guide is a real important part of the GUI...), oh I think I got off track. Anyway X is a base to build GUIs on, and one could imitate the OSX GUI (more or less -- Alpha transparency between the new GUIs apps an other apps could be a pain).
In fact people have been working on it for a while, go look at GNUStep, it's not Cocoa, but it's what Cocoa was before Apple bought it, and doing the rest is doable. Not a trivial afternoon's work, but not a decade long effort either.
Unfortunately, you, AC (and the original poster), do not understand Mac OS X.
And while you may, you don't seem to have a great handle on X11...not that it is an easy thing to understand, or all that frequently a useful thing to understand...
You don't need to be root to install. If you run the installer, you merely need to authenticate as an administrator (admin != root).
Fire up top next time you do that...you'll see that when you give the installer the admin password it uses it to run something as root (or to transform into a root process itself via some Mach magic). You may not count that as "being root to install", but I do.
Or, any user can just copy the Office folder from the CD to wherever they like (like, say ~/Applications/Office rather than/Applications/Office)
That's pretty cool, I didn't know that. I like that kind of installer more.
Older apps (mac os 7-8-9) still run in a compatability mode.
Plus OS 6, 5, 4, 3, 2, and (I expect) 1. I've run a pre-release MacDraw under OSX. Pretty amazing to see that old 68000 program running on a totally different CPU on a totally different OS...
Of corse your better off getting AppleWorks for OSX, I mean the draw program there even knows what color is:-)
Carbon Applications are every bit as Unix as Cocoa
Sure, but both require a giant library of stuff to work. Oddly enough the newer lib (Cocoa) is easier to port to random Unix systems because it is more or less NeXTStep. The other lib is more or less 90% of the old MacOS API.
Sure, you can port a Carbon program to a Unix system (give the source code), as long as you implement 90% of MacOS 9 in a user level library. Of corse you could port a Carbon program to VMS, PalmOS, VM/CMS, or the ROM monitor on a SPARC if only you implement 90% of MacOS 9 for it...
Doable, but not easy.
I think this confusion is Apple's fault. They use terminology like a Terminal window "letting you talking directly to the Unix kernel". This is crap, the shell is just another program. They mystify Unix and make it sound harder than it really is.
Of corse they do, it makes it sound somehow cool, and also like normal Mac users will never have to learn a single thing about it (and they don't...unless they were the kind of Mac user that fiddled with ResEdit for the fun of it).
In short, unless it is running in the classic environment (they all run as one application), it is a Unix Application
Yeah, but not in the sense that it is easy to port to another Unix. I keep struggling for a good analogy, and coming up with nothing. At least nothing stunning. It's a lot like taking a PhotoShop plugin that happens to work on a Windows machine, and saying "look it runs on Windows, it's a Windows program". Sure it is. In theory it could be run without PhotoShop, in practice it's a real pain to recreate enough of PhotoShop to run PhotoShop plugins (or worse yet, actions).
So yeah, with the exception of Classic stuff that runs under OSX are Unix programs, but not always in a useful way!
There are two languages used for programming mac OS X. Carbon and Cocoa.
Er, those are APIs, not languages. There is a C language binding for Carbon, and probably an assembly one, and maybe Pascal... Cocoa has a ObjectaveC binding, and a Java binding, and with the newer dev kit it may sort of have a C++ binding, or maybe that's just the ability to do some sort of twisted intermingling of C++ and ObjC.
Cocoa would be NEARLY IMPOSSIBLE to port to unix because it is in OBJECTIVE C and it is deeply rooted in the event based model classes of mac OS X.
Sure, unless you could somehow get an ObjectaveC compiler...like gcc. Oh, and a ObjC runtime system...like the GNU version of NeXTStep (which I thought was AfterStep, but that may just be a window manager...I know there is one though). Cocoa is mostly NeXTStep, down to all the classes being named things like NSfoo. There have been some people busily cloning under Unix it for the better part of a decade.
Unless you think it is going to run in the terminal, M$ will have a hell of a time trying to port it to unix.
Well, if they did it in Cocoa they may be able to use the NeXTStep clone, more likely they did it in Carbon, and the best bet for that would have been a company that did a Mac API clone some years ago, but I think they went bankrupt in the very early '90s because almost nobody wanted to port Mac apps to Unix, even if they made it a pretty trivial port.
More importantly, the Mac has about 5% of the desktop market (as of the start of 2001 -- it may have gone up, Apple had a pretty good year with the iBook and TiBook). That's pretty small, but Unix in general (not counting OSX) has a smaller share, and there is some effort in porting between them (should be minimal for well written apps -- they even frequently "just work"; but that doesn't help staff a support center with everything they need). Is it worth MS's money to port Office to other Unix systems? Even if MS didn't have a vested interest in keeping everybody out of their party?
I don't think it really does. That's not to say they wouldn't give Linux the big miss even if they thought they could recoup their porting investment, but I doubt they could. How much money is Loki making (and Loki has a bunch of portability libs they have written already...).
Euros are not that simple like the US Dollar. They contain holograms, micro-writings, special embroidery, water marks, metal twines
FYI, the "new" US bills have holographic ink, micro writing, water marks, and UV ink. I don't think it has metal twines or special embroidery (except the UV ink is really a UV ink thread, different "color" for each value of bill, different place too).
The "new" bills have been out for a while as $100, $50, and $20. The $10 and $5 are kind of recent (this last summer?), and the $1 isn't out, or at least I have not seen them.
very cheap paper
Eh? The show about the "new" bills talked a lot about how they decided the paper was very good and very hard to match, and not worth changing, and the same for the ink (except for the holographic part, and the UV part).
Re:If only Transmeta would release a different CPU
on
Via One-ups Transmeta
·
· Score: 2
So what's the point of code morphing?
Well for one thing it dances around a lot of Intel's and AMD's patents.
I mean, if they're just going to be a low-power x86 clone, surely the resources (engineering, space on the die, whatever) taken up by code morphing could be put to better use as...nothing. Just make an x86-only design. AMD did, and theirs is better.
Maybe, but AMD also spent a lot more on research. Money TM didn't have. AMD's also came out a while after TM's CPU.
Personally I think TM blew it with their first CPU that didn't run 16bit code very quickly at all, and lost a ton of time doing the second CPU which did run 16 and 32 bit code fairly well. If they had payed more attention to 16 bit code they may have brought out the TM CPUs quickly enough that they didn't seem so slow. Remember everyone else's CPUs were getting faster. Especally right then, AMD and Intel had just finished the race for 1Ghz, six to eight months earlyer and the TM CPU would have be every bit as fast as the notebook CPUs that were out.
Of corse that's just a thery, and I have no real evidence.
Seriously. Either develop some useful capability from the code morphing tech, or abandon it.
Who says they havn't? It did give them a faster time to market, they had a number of bugs in their CPUs that they coded around in the morphing engine (instruction combos that should work, but didn't, the morpher was change to not pair them).
The code morphing tech's useful capability may well be that TM actually has something on the market, and hasn't been sued by all the other x86 makers for patent infringment. That may not save TM from being an "also ran", but it doesn't make code morphing a bad idea.
(Also just because TM aimed at low power doesn't mean that's the only place code morphing can be used -- it's not that diffrent from microcoded CPUs, or trace scheduling. With diffrent goals it may be useful to make fast CPUs, or just plain not)
TM had a lot of obsticles, far more then most CPUs have. Definitly more then the one CPU I designed (in a class, not the real world). Being crushed by them doesn't mean all their choices were bad.
Re:If only Transmeta would release a different CPU
on
Via One-ups Transmeta
·
· Score: 2
Wouldn't it be great if you could run mac software at the flick of a switch? I agree, for the performance some more silicon may have to beadded. But if you don't optimize very much at the start you wouldn't need that much extra.
Still makes the software design (code morpher, and BIOS) about 100% more complex. Maybe only about 50% more complex since they did a Java version. It would also help hilight it's slowness "Can't even keep up with a dead 300Mhz Mac", and "Jack of all trades, Master of none" are not headlines they need.
As for running Mac software, it is great to be able to run it at the flick of a switch (or at least the opening of a lid), but it's great to actually be able to not see OSX draw each and every pixel. Really, if the existing TM hardware were asked to emulate a PowerPC it wouldn't be able to hold more then one CPU state in it's registers, so no real speculatave execution, making it's write guards useless, and it's fast shadow save and restore instructions useless as well. Cutting off whole sections of the functionality, and most of the opertunity to actually emulate a CPU better then CPUs not designed to do emulation.
Let me repeat that part, because of the differences between it's target system and what it is trying to do pretty much everything put into the TM hardware to help it emulate a CPU is worthless. For speed you would be better off doing the emulator on a P4, or a recent Alpha.
Going for the biggest market share is not always the point. It is like saying 90% of word for windows is not used, let's cut 90% of word for windows, making it 100% faster etc etc. However not the same 10% is used by everyone.
But you are not doing a faster subset of the PowerPC here, you are doing a whole PowerPC that is slower then the existing embeded PPC designs, costs more, uses more power, and has fewer integrated parts. The only advantage to your proposed slow PPC is it is also a slow x86 and uses very little power for an x86.
Plus pretty much only Apple can make a computer run Mac OS (this is a lot less true with OS X around), and I doubt they would try to provide a very slow laptop that can run PC software faster then Mac software. They would either see it as a bridge away from the Mac, or as an amusing diversion almost nobody would buy. As cool as the iBook is, I wouldn't pay more then $500 for a 300Mhz one given what they currently have on the market for $875! No, I won't even buy it for $500, I wouldn't hesitate at $200 though.
P.S. yes the 300Mhz number is pretty made up, it is around half what people say the x86 feels like. The real number could be a lot lower, but I doubt it will be a lot higher. In fact if Apple is right, it is a lot lower even if they make it feel like a 500Mhz x86 -- but I think they are wrong about the G3 being much faster per Mhz. They are right about the G4 for some tasks though.
Re:Speaking of laptop power savings: LED backlight
on
Via One-ups Transmeta
·
· Score: 2
Because they look crappy?
They look fine on my PS100, and D30. Nice even light, and decently bright (the PS100 can be seen in fairly bright sunlight, the D30 can't though), and no strong color casts. They seem to work decently in low and high temperatures (the iPod backlight, or maybe LCD doesn't seem to work so well in the cold, and I think it has a LED backlight).
I would believe "you can't make them big enough", or "can't make 'em big and cheep", or even "they have been using them for 14 months!", but I'm not buying "they look crappy".
PocketApps (ie: PocketWord and other apps I dont' know why anyone would want on a PDA)
Well PocketWord may not be what you want to take notes with, and you may not want to write a report on a PDA, but it's pretty good for reading MS Office documents, which you may want to do on a PDA. Well not want, so much as having other people send you documents in rather then something nice like PostScript, DVI (see TeX), or even PDF, and the documents may contain things you need to know, and the PDA may be a good place to keep them, and you may want to refer to them...
Of corse the amazing size of some Word files makes it easy to explain why WinCE machines sell big CF cards. I have had a single page all text document (1 or 2 fonts, no logos, normal font size) take up over 1M for no apparent reason.
Wouldn't it be cool to have a machine that could run every platform from Windows XP to MAME to Commodore BASIC to PDP-11 Unix?
They buy them all the time. They buy "PC Compatibles". They can run Windows, Unix, C=64 emulators, MAME, and some fine PDP-11 emulators which run faster then the real PDPs.
You really only need to buy CPUs designed to emulate other CPUs to try to emulate current-ish platforms. If you are interested in anything older then about 3 turns of the crank for Moore's "Law" a normal CPU will be fine (well unless you want to emulate historic supercomputers, then you may need 5 turns, or to emulate a mainframe then you may need something with lots of I/O...unless it is even older).
Re:If only Transmeta would release a different CPU
on
Via One-ups Transmeta
·
· Score: 3, Insightful
All that code morphing stuff should enable a laptop to be made with a switch labeled "G4" or "x86"
The TM CPUs have a lot of x86 like functionality wired into them. Sure they don't execute x86 code, but they do have x86 style MMUs, not PowerPC ones. They do set their condition flags based on when an x86 would, not a PowerPC. The 40 or so GP registers they have is plenty to try to emulate a CPU that only has 4 or so, but not so good for CPUs that really have 16 or 32 (you need to use some registers for the morphing code, some to hold state that may not come to pass, some...).
The current Transmeta chips are not x86 CPUs, but they emulate x86 CPUs far far better then they can emulate any other CPU. This could be addressed by future TM CPUs, but only by adding things that mostly wouldn't be of use to them while being an x86, so if x86 is where 95+% of the market is, it may make sense to not even make the TM CPUs 6% more complex... let alone the morphing software 100% more complex.
Re:Don't judge Perl based on the article
on
Happy Birthday Perl!
·
· Score: 3, Interesting
Unless you are making the jump from procedural to OOP, or OOP to Functional for the first time, you *CAN* pick up a book and learn a new language in a days time
I agree with the thrust of your argument, but there are a lot more then the 2 exceptions you listed above that can seriously lengthen the learning gap, and many are losses of language/lib features.
Going from explicit to implicit memory management will generally not be too hard, but going from only languages that GC (or reference count) for you to ones that don't is a big jump. Going from things with random access pointers (C, and assembly) to things that don't (Java, Pascal...) will also be a bit of a hinderance. Losing floating point can be a shock (most languages to FORTH). Oh, going to a stack language can be a shock (PostScript and FORTH). So can going from strongly typed languages (Java/ADA) to weakly typed ones (C) can be a shock as well, but so can going to untyped languages (FORTH), and this shock works both ways. Oh, and losing exception handling (APL/C++/
Modula-3 to C) can be a shock as well.
There are dozens more that can throw one for a loop (Hmmm, explicit flow control, vs. data flow languages anyone?). Not every languages has them (some have many), and once you start learning lots of languages chances increase that the new language won't have any new concepts, but just a new (and hopefully more useful) combination of them.
Oh, and learning some of the finer points of languages can take some time ("resource acquisition is object creation" for example), I used C++ for five years before I stumbled across that one (to be honest, I think I used C++ for two years before one could fully apply that one).
ou can't (or won't) encrypt EVERY protocol. DNS, DHCP, ICMP? All of these aren't worth adding application-layer encryption, but do provide valuable data to an attacker.
IPsec for IPv6 (and I assume IPv4) is pretty flexible and can be used on UDP (DNS, DHCP), and I *think* ICMP (it would be useful for the "had to fragment, but couldn't" packets as well as redirects, but since it isn't required there it won't really help).
That said there is very little wrong with packet level encryption, about the only two "wrong" things are fooling people into thinking they don't need session level encryption, and, um, fooling people into thinking they don't need session level encryption:-)
Wow, nothing captures the grandeur and rich detail of a 1000+ page epic like 128 colors, 160x200 resolution rendered by a graphics chip running at 1.19 MHz.
Graphics chip? I doubt there was a whole chip dedicated to the graphics (or looking at it another way -- only one). The 2600 didn't have hardware acceleration, or even a bitmapped display. It had one register that you loaded the value to feed to the color guns! Want blue for 8 pixels? Load 0b001100 into the color guns and loop for 8 pixel durations. Oh? You wanted to do some work while the screen is drawing? Well then, you are in for a whole world of hurt...
How many of you would sign up for the service if the recievers were at no or low cost?
Not me, I would have to give up my 3 CD in dash player with all kinds of Dolby crap. If it was already built in, or if the replacement also did all the crap my existing "radio" does and was free including install then sure, I would sign up for a month and decide if I liked it.
I think a lot of people are in a sort of similar boat (willing to sign up for a month if the receiver incl. install was free -- I'm not so sure others have my "high standards" for a replacement "radio").
I doubt they'll be able to survive the 3-4 years it will take until this could be a standard feature in car and home radios.
I thought GM was going to include it standard on many cars, and as an option on pretty much all of them starting "real soon now". Plus last time I looked at car radios over half of them seemed to have XM, a lot more then could do "CD MP3".
Notice how the FCC decency rules apply to standard cable, but not HBO... I bet that within 5 years they'll apply to HBO too.
I think "standard" cable chooses to be conservative in what they air. It pisses me off, I have written to CourTV to tell them I don't watch NYPD Blue reruns that they air because they choose to bleep out dialog (and "airbrush" some body parts) the network TV has already aired!
At any rate the networks are getting more bold, not less. I also don't see HBO caving many of their most popular shows (Sopranos, Sex in the City) have nudity in pretty much each episode.
As for correcting the problem at the source, I would be happy to drop the whole lame censoring scheme we use, but many people still support it. In fact I recall writing my congress critter that I was in full support of the "V chip" crap if and only if it allowed any channel to broadcast as much sex and violence as they though was proper so long as it was labeled. I mean, if a parent doesn't want a child seeing that sort of thing, the V chip would stop it, right? If not, what good is it?
I would assume nothing stops XM from broadcasting whichever version of the music they like, the question is which version do they think makes more money? (personally I like some of the "cut" version better, not because the words offend me, but some of the digital scratch out effects that Rage used were pretty cool sounding, better then "Fuck you, I won't do what you tell me!", but for the most part the uncut versions are better)
P.S. My Mac's spell check (OSX -- it's unix for the one button crowd!) doesn't have "fuck", one of the suggestions was "fsck"...
Those are also areas where people are also spread very thinly. You're not going to pay for your satellite network with 15% of those people; you're going to need 3% of the suburban drivers.
Yeah, but you can probably get a lot more then 15% of them. They were the early adopters for satellite TV too you know... (of course BUD's day has passed, but...). Now 90% of them may still leave you needing 2.5% of the suburban drivers, but I'm guessing you'll get more rural folks signing up then home subscribers in the near future.
Not that this is really to my taste, I have a ton of music channels on my dish, and hardly ever bother.
Unless I'm mistaken, #import works perfectly well in C and C++ source, at least when compiled with gcc, where -Wno-import is set.
I don't doubt that it works in gcc, but it sure isn't part of C or C++. It is something gcc does for you (in part because it is also an ObjC compiler).
If some day you decide to use SGI's IA64 compiler, or Intels C compiler, or Mertoworks there is a good chance that #import will just plain not work.
It's fine if you like to use it, but understand it's no better then a Microsoft C user claiming that exception handling is part of C, not C++ just because MS decided it should work that way.
(Of corse it's no worse then a gcc user deciding to use// comments in C code in 1998, who won the bet because as of C99 it really is part of C, not just C++ and PL/1...)
Er, sort of. There is one new "call syntax", which includes new syntax for unordered arguments as well as calling through an object. There is one new preprocessor macro to replace (or at least augment) #include. There is a whole new declaration syntax for objects as well. That is more like three things. And it may be as many as eight.
Now that doesn't compare to C++ which is described in less detail by a book 5 times as thick as K&R C, but it is a little more then one change.
(and having used both, I miss some of the C++ stuff, but not as much as I'll never mind is gone)
One of the big problems with writing GUIs in C++ is that the type system gets in the way. The kludges neccessary to support a GUI system on C++ are infamous. Most systems resort to macros. GTK-- uses templates
Templates are not a kludge, so GTK-- being "forced" to use them isn't a big deal (in fact GTK-- is a very nice API -- it's big kludge is that it is really just a wrapper so if you write new GTK-- widgets, people using GTK in Python will have a hard time using them!).
Now I will admit that C++ is a pretty nasty language, and my minimal exposure with ObjC makes me thing that ObjC is nicer, except it lacks templates, and thus anything like the wonderful STL. Of corse it also lacks six different kinds of multiple inheritance (or seems to at any rate), which is a good thing.
These devices look like they will significantly reduce the cost of PDA's and other handheld devices as well as replacing analog film
According to the article the plan on making storage that can hold 300 or so 1Mpixel digital images. I have a ComapctFlash card that holds about 200 3Mpixel images, it cost me $110 (on sale ). I figure they hold about the same amount of data as the 3D chips are intended to. So this new technology can make a $110 CF card even cheaper, but not by more then $110. Realistically, probably not more then $100 or $80 cheaper...
And it won't make cameras cheaper at all since camera makers seldom include CF cards of a useful size at all (my latest camera came with a 8M card, enough to hold fewer then 8 normal pictures, maybe 3 raw format ones -- less then a second of shooting at full speed!).
It might even make the cameras slightly more costly as venders finally decide to ship "useful" sized CF cards (which is not as good as one may think -- would you want to pay $30 extra to get a 340M CF card when your real plan is to pay $60 for a 1G CF card?)
Is it illegal, then, to listen to other peoples' shouted conversations in public places? What if it's an interesting conversation, and you crane your neck in to hear more of it? What if it proves sufficiently enticing to you that you choose to join in with your own anecdotes?
I don't think it is illegal, but I don't know for sure. I would be supprised if it were...
Does it make a difference if the shouting consists of pressure waves in air (sound) or electromagnetic radiation (RF)?
Should it? No, I don't think so. Does it? Yes. In the USA at least it is illegal to spy on cordless phone usage (unless you have a wiretap warrent, or unless the anti-terroism act changed this). That is pretty damm public. similar for cell phones. Neither are as well encoded as 802.11 with WEP.
For the most part geeks, nerds, and engenears do not make laws, or intrepret them. Lawyers, ex-lawyers, and judges do. Mostly. As a geek once in a while you might get to advise lawmakers, or even appear before a judge as a witness, but that's pretty much it.
There is not a more public slice of spectrum than the 2.4GHz band used by 802.11b.
I think you left the visable light part out. And there are laws dealing with that. Mostly that if it is visable from your property or public property you can take a picture of it (unless it is child porn, I asume, or a milatary secret, maybe), but you can't sell the picture for profit in many cases (in others you can). You can look on photo.net for more detail.
As a user of a medium-range (several miles) 802.11b link, by which I'm accessing Slashdot right now, I'm acutely aware of this. Anything I don't want to say in public is treated, at least, with SSH before it hits the air.
That is a good idea since SSH can keep the Bad Thing from happening, while laws can only punish those who did the Bad Thing (and frequently those who are doing a Harmless Thing, at least Harmless To Others).
Plus as far as I know there have been no cases about this, so we don't know how it will turn out.
Slashdot Mirror
Er, is there any problem with "all of them"? I've written a bunch of X apps, and none of them give a crap what window manager you run them under.
The rest of your argument looks more or less correct, look at all the complaints about Mozilla using GTK and not Qt, and then about it not really using GTK so much, and...
Of corse that didn't stop other Unix apps from making the choices (normally badly -- er, I mean normally Motif), and not get too many complaints...well, maybe a lot of complaints, but they are easy to brush off...mostly because I have no access to explosives, no, wait, I didn't say that out loud.
Cocoa is NeXTStep, right down to things being named NSfoo. Well, it is NeXTStep, plus some extra development, but not a ton of extra stuff (I guess they were busy doing other things).
So something that could run NeXTStep apps could run a subset of Cocoa apps. More importantly if the thing that ran NeXTStep apps were extended to do the extra things (like sheets, and adding "display PDF" (not too hard given Display PostScript)) it could probably run a lot of Cocoa stuff...
Where could we find something like that? Maybe GNUStep? I mean they have been working on it for a long time...
P.S. X Windows isn't a GUI. It's a rendering engine, and a method to get raw user input. Gtk and Qt are more like GUIs (technically they are just GUI toolkits, a big paper document called a User Interface guide is a real important part of the GUI...), oh I think I got off track. Anyway X is a base to build GUIs on, and one could imitate the OSX GUI (more or less -- Alpha transparency between the new GUIs apps an other apps could be a pain).
In fact people have been working on it for a while, go look at GNUStep, it's not Cocoa, but it's what Cocoa was before Apple bought it, and doing the rest is doable. Not a trivial afternoon's work, but not a decade long effort either.
And while you may, you don't seem to have a great handle on X11...not that it is an easy thing to understand, or all that frequently a useful thing to understand...
Fire up top next time you do that...you'll see that when you give the installer the admin password it uses it to run something as root (or to transform into a root process itself via some Mach magic). You may not count that as "being root to install", but I do.
That's pretty cool, I didn't know that. I like that kind of installer more.
Plus OS 6, 5, 4, 3, 2, and (I expect) 1. I've run a pre-release MacDraw under OSX. Pretty amazing to see that old 68000 program running on a totally different CPU on a totally different OS...
Of corse your better off getting AppleWorks for OSX, I mean the draw program there even knows what color is :-)
FYI, under OSX you don't need to be root to run it, but you do to install it (same with many other programs).
Sure, but both require a giant library of stuff to work. Oddly enough the newer lib (Cocoa) is easier to port to random Unix systems because it is more or less NeXTStep. The other lib is more or less 90% of the old MacOS API.
Sure, you can port a Carbon program to a Unix system (give the source code), as long as you implement 90% of MacOS 9 in a user level library. Of corse you could port a Carbon program to VMS, PalmOS, VM/CMS, or the ROM monitor on a SPARC if only you implement 90% of MacOS 9 for it...
Doable, but not easy.
Of corse they do, it makes it sound somehow cool, and also like normal Mac users will never have to learn a single thing about it (and they don't...unless they were the kind of Mac user that fiddled with ResEdit for the fun of it).
Yeah, but not in the sense that it is easy to port to another Unix. I keep struggling for a good analogy, and coming up with nothing. At least nothing stunning. It's a lot like taking a PhotoShop plugin that happens to work on a Windows machine, and saying "look it runs on Windows, it's a Windows program". Sure it is. In theory it could be run without PhotoShop, in practice it's a real pain to recreate enough of PhotoShop to run PhotoShop plugins (or worse yet, actions).
So yeah, with the exception of Classic stuff that runs under OSX are Unix programs, but not always in a useful way!
Er, those are APIs, not languages. There is a C language binding for Carbon, and probably an assembly one, and maybe Pascal... Cocoa has a ObjectaveC binding, and a Java binding, and with the newer dev kit it may sort of have a C++ binding, or maybe that's just the ability to do some sort of twisted intermingling of C++ and ObjC.
Sure, unless you could somehow get an ObjectaveC compiler...like gcc. Oh, and a ObjC runtime system...like the GNU version of NeXTStep (which I thought was AfterStep, but that may just be a window manager...I know there is one though). Cocoa is mostly NeXTStep, down to all the classes being named things like NSfoo. There have been some people busily cloning under Unix it for the better part of a decade.
Well, if they did it in Cocoa they may be able to use the NeXTStep clone, more likely they did it in Carbon, and the best bet for that would have been a company that did a Mac API clone some years ago, but I think they went bankrupt in the very early '90s because almost nobody wanted to port Mac apps to Unix, even if they made it a pretty trivial port.
More importantly, the Mac has about 5% of the desktop market (as of the start of 2001 -- it may have gone up, Apple had a pretty good year with the iBook and TiBook). That's pretty small, but Unix in general (not counting OSX) has a smaller share, and there is some effort in porting between them (should be minimal for well written apps -- they even frequently "just work"; but that doesn't help staff a support center with everything they need). Is it worth MS's money to port Office to other Unix systems? Even if MS didn't have a vested interest in keeping everybody out of their party?
I don't think it really does. That's not to say they wouldn't give Linux the big miss even if they thought they could recoup their porting investment, but I doubt they could. How much money is Loki making (and Loki has a bunch of portability libs they have written already...).
FYI, the "new" US bills have holographic ink, micro writing, water marks, and UV ink. I don't think it has metal twines or special embroidery (except the UV ink is really a UV ink thread, different "color" for each value of bill, different place too).
The "new" bills have been out for a while as $100, $50, and $20. The $10 and $5 are kind of recent (this last summer?), and the $1 isn't out, or at least I have not seen them.
Eh? The show about the "new" bills talked a lot about how they decided the paper was very good and very hard to match, and not worth changing, and the same for the ink (except for the holographic part, and the UV part).
Well for one thing it dances around a lot of Intel's and AMD's patents.
Maybe, but AMD also spent a lot more on research. Money TM didn't have. AMD's also came out a while after TM's CPU.
Personally I think TM blew it with their first CPU that didn't run 16bit code very quickly at all, and lost a ton of time doing the second CPU which did run 16 and 32 bit code fairly well. If they had payed more attention to 16 bit code they may have brought out the TM CPUs quickly enough that they didn't seem so slow. Remember everyone else's CPUs were getting faster. Especally right then, AMD and Intel had just finished the race for 1Ghz, six to eight months earlyer and the TM CPU would have be every bit as fast as the notebook CPUs that were out.
Of corse that's just a thery, and I have no real evidence.
Who says they havn't? It did give them a faster time to market, they had a number of bugs in their CPUs that they coded around in the morphing engine (instruction combos that should work, but didn't, the morpher was change to not pair them).
The code morphing tech's useful capability may well be that TM actually has something on the market, and hasn't been sued by all the other x86 makers for patent infringment. That may not save TM from being an "also ran", but it doesn't make code morphing a bad idea.
(Also just because TM aimed at low power doesn't mean that's the only place code morphing can be used -- it's not that diffrent from microcoded CPUs, or trace scheduling. With diffrent goals it may be useful to make fast CPUs, or just plain not)
TM had a lot of obsticles, far more then most CPUs have. Definitly more then the one CPU I designed (in a class, not the real world). Being crushed by them doesn't mean all their choices were bad.
Still makes the software design (code morpher, and BIOS) about 100% more complex. Maybe only about 50% more complex since they did a Java version. It would also help hilight it's slowness "Can't even keep up with a dead 300Mhz Mac", and "Jack of all trades, Master of none" are not headlines they need.
As for running Mac software, it is great to be able to run it at the flick of a switch (or at least the opening of a lid), but it's great to actually be able to not see OSX draw each and every pixel. Really, if the existing TM hardware were asked to emulate a PowerPC it wouldn't be able to hold more then one CPU state in it's registers, so no real speculatave execution, making it's write guards useless, and it's fast shadow save and restore instructions useless as well. Cutting off whole sections of the functionality, and most of the opertunity to actually emulate a CPU better then CPUs not designed to do emulation.
Let me repeat that part, because of the differences between it's target system and what it is trying to do pretty much everything put into the TM hardware to help it emulate a CPU is worthless. For speed you would be better off doing the emulator on a P4, or a recent Alpha.
But you are not doing a faster subset of the PowerPC here, you are doing a whole PowerPC that is slower then the existing embeded PPC designs, costs more, uses more power, and has fewer integrated parts. The only advantage to your proposed slow PPC is it is also a slow x86 and uses very little power for an x86.
Plus pretty much only Apple can make a computer run Mac OS (this is a lot less true with OS X around), and I doubt they would try to provide a very slow laptop that can run PC software faster then Mac software. They would either see it as a bridge away from the Mac, or as an amusing diversion almost nobody would buy. As cool as the iBook is, I wouldn't pay more then $500 for a 300Mhz one given what they currently have on the market for $875! No, I won't even buy it for $500, I wouldn't hesitate at $200 though.
P.S. yes the 300Mhz number is pretty made up, it is around half what people say the x86 feels like. The real number could be a lot lower, but I doubt it will be a lot higher. In fact if Apple is right, it is a lot lower even if they make it feel like a 500Mhz x86 -- but I think they are wrong about the G3 being much faster per Mhz. They are right about the G4 for some tasks though.
They look fine on my PS100, and D30. Nice even light, and decently bright (the PS100 can be seen in fairly bright sunlight, the D30 can't though), and no strong color casts. They seem to work decently in low and high temperatures (the iPod backlight, or maybe LCD doesn't seem to work so well in the cold, and I think it has a LED backlight).
I would believe "you can't make them big enough", or "can't make 'em big and cheep", or even "they have been using them for 14 months!", but I'm not buying "they look crappy".
Well PocketWord may not be what you want to take notes with, and you may not want to write a report on a PDA, but it's pretty good for reading MS Office documents, which you may want to do on a PDA. Well not want, so much as having other people send you documents in rather then something nice like PostScript, DVI (see TeX), or even PDF, and the documents may contain things you need to know, and the PDA may be a good place to keep them, and you may want to refer to them...
Of corse the amazing size of some Word files makes it easy to explain why WinCE machines sell big CF cards. I have had a single page all text document (1 or 2 fonts, no logos, normal font size) take up over 1M for no apparent reason.
They buy them all the time. They buy "PC Compatibles". They can run Windows, Unix, C=64 emulators, MAME, and some fine PDP-11 emulators which run faster then the real PDPs.
You really only need to buy CPUs designed to emulate other CPUs to try to emulate current-ish platforms. If you are interested in anything older then about 3 turns of the crank for Moore's "Law" a normal CPU will be fine (well unless you want to emulate historic supercomputers, then you may need 5 turns, or to emulate a mainframe then you may need something with lots of I/O...unless it is even older).
The TM CPUs have a lot of x86 like functionality wired into them. Sure they don't execute x86 code, but they do have x86 style MMUs, not PowerPC ones. They do set their condition flags based on when an x86 would, not a PowerPC. The 40 or so GP registers they have is plenty to try to emulate a CPU that only has 4 or so, but not so good for CPUs that really have 16 or 32 (you need to use some registers for the morphing code, some to hold state that may not come to pass, some...).
The current Transmeta chips are not x86 CPUs, but they emulate x86 CPUs far far better then they can emulate any other CPU. This could be addressed by future TM CPUs, but only by adding things that mostly wouldn't be of use to them while being an x86, so if x86 is where 95+% of the market is, it may make sense to not even make the TM CPUs 6% more complex... let alone the morphing software 100% more complex.
I agree with the thrust of your argument, but there are a lot more then the 2 exceptions you listed above that can seriously lengthen the learning gap, and many are losses of language/lib features.
Going from explicit to implicit memory management will generally not be too hard, but going from only languages that GC (or reference count) for you to ones that don't is a big jump. Going from things with random access pointers (C, and assembly) to things that don't (Java, Pascal...) will also be a bit of a hinderance. Losing floating point can be a shock (most languages to FORTH). Oh, going to a stack language can be a shock (PostScript and FORTH). So can going from strongly typed languages (Java/ADA) to weakly typed ones (C) can be a shock as well, but so can going to untyped languages (FORTH), and this shock works both ways. Oh, and losing exception handling (APL/C++/ Modula-3 to C) can be a shock as well.
There are dozens more that can throw one for a loop (Hmmm, explicit flow control, vs. data flow languages anyone?). Not every languages has them (some have many), and once you start learning lots of languages chances increase that the new language won't have any new concepts, but just a new (and hopefully more useful) combination of them.
Oh, and learning some of the finer points of languages can take some time ("resource acquisition is object creation" for example), I used C++ for five years before I stumbled across that one (to be honest, I think I used C++ for two years before one could fully apply that one).
IPsec for IPv6 (and I assume IPv4) is pretty flexible and can be used on UDP (DNS, DHCP), and I *think* ICMP (it would be useful for the "had to fragment, but couldn't" packets as well as redirects, but since it isn't required there it won't really help).
That said there is very little wrong with packet level encryption, about the only two "wrong" things are fooling people into thinking they don't need session level encryption, and, um, fooling people into thinking they don't need session level encryption :-)
Graphics chip? I doubt there was a whole chip dedicated to the graphics (or looking at it another way -- only one). The 2600 didn't have hardware acceleration, or even a bitmapped display. It had one register that you loaded the value to feed to the color guns! Want blue for 8 pixels? Load 0b001100 into the color guns and loop for 8 pixel durations. Oh? You wanted to do some work while the screen is drawing? Well then, you are in for a whole world of hurt...
Not me, I would have to give up my 3 CD in dash player with all kinds of Dolby crap. If it was already built in, or if the replacement also did all the crap my existing "radio" does and was free including install then sure, I would sign up for a month and decide if I liked it.
I think a lot of people are in a sort of similar boat (willing to sign up for a month if the receiver incl. install was free -- I'm not so sure others have my "high standards" for a replacement "radio").
I thought GM was going to include it standard on many cars, and as an option on pretty much all of them starting "real soon now". Plus last time I looked at car radios over half of them seemed to have XM, a lot more then could do "CD MP3".
I think "standard" cable chooses to be conservative in what they air. It pisses me off, I have written to CourTV to tell them I don't watch NYPD Blue reruns that they air because they choose to bleep out dialog (and "airbrush" some body parts) the network TV has already aired!
At any rate the networks are getting more bold, not less. I also don't see HBO caving many of their most popular shows (Sopranos, Sex in the City) have nudity in pretty much each episode.
As for correcting the problem at the source, I would be happy to drop the whole lame censoring scheme we use, but many people still support it. In fact I recall writing my congress critter that I was in full support of the "V chip" crap if and only if it allowed any channel to broadcast as much sex and violence as they though was proper so long as it was labeled. I mean, if a parent doesn't want a child seeing that sort of thing, the V chip would stop it, right? If not, what good is it?
I would assume nothing stops XM from broadcasting whichever version of the music they like, the question is which version do they think makes more money? (personally I like some of the "cut" version better, not because the words offend me, but some of the digital scratch out effects that Rage used were pretty cool sounding, better then "Fuck you, I won't do what you tell me!", but for the most part the uncut versions are better)
P.S. My Mac's spell check (OSX -- it's unix for the one button crowd!) doesn't have "fuck", one of the suggestions was "fsck"...
Yeah, but you can probably get a lot more then 15% of them. They were the early adopters for satellite TV too you know... (of course BUD's day has passed, but...). Now 90% of them may still leave you needing 2.5% of the suburban drivers, but I'm guessing you'll get more rural folks signing up then home subscribers in the near future.
Not that this is really to my taste, I have a ton of music channels on my dish, and hardly ever bother.
I don't doubt that it works in gcc, but it sure isn't part of C or C++. It is something gcc does for you (in part because it is also an ObjC compiler).
If some day you decide to use SGI's IA64 compiler, or Intels C compiler, or Mertoworks there is a good chance that #import will just plain not work.
It's fine if you like to use it, but understand it's no better then a Microsoft C user claiming that exception handling is part of C, not C++ just because MS decided it should work that way.
(Of corse it's no worse then a gcc user deciding to use // comments in C code in 1998, who won the bet because as of C99 it really is part of C, not just C++ and PL/1...)
Er, sort of. There is one new "call syntax", which includes new syntax for unordered arguments as well as calling through an object. There is one new preprocessor macro to replace (or at least augment) #include. There is a whole new declaration syntax for objects as well. That is more like three things. And it may be as many as eight.
Now that doesn't compare to C++ which is described in less detail by a book 5 times as thick as K&R C, but it is a little more then one change.
(and having used both, I miss some of the C++ stuff, but not as much as I'll never mind is gone)
Templates are not a kludge, so GTK-- being "forced" to use them isn't a big deal (in fact GTK-- is a very nice API -- it's big kludge is that it is really just a wrapper so if you write new GTK-- widgets, people using GTK in Python will have a hard time using them!).
Now I will admit that C++ is a pretty nasty language, and my minimal exposure with ObjC makes me thing that ObjC is nicer, except it lacks templates, and thus anything like the wonderful STL. Of corse it also lacks six different kinds of multiple inheritance (or seems to at any rate), which is a good thing.
According to the article the plan on making storage that can hold 300 or so 1Mpixel digital images. I have a ComapctFlash card that holds about 200 3Mpixel images, it cost me $110 (on sale ). I figure they hold about the same amount of data as the 3D chips are intended to. So this new technology can make a $110 CF card even cheaper, but not by more then $110. Realistically, probably not more then $100 or $80 cheaper...
And it won't make cameras cheaper at all since camera makers seldom include CF cards of a useful size at all (my latest camera came with a 8M card, enough to hold fewer then 8 normal pictures, maybe 3 raw format ones -- less then a second of shooting at full speed!).
It might even make the cameras slightly more costly as venders finally decide to ship "useful" sized CF cards (which is not as good as one may think -- would you want to pay $30 extra to get a 340M CF card when your real plan is to pay $60 for a 1G CF card?)
I don't think it is illegal, but I don't know for sure. I would be supprised if it were...
Should it? No, I don't think so. Does it? Yes. In the USA at least it is illegal to spy on cordless phone usage (unless you have a wiretap warrent, or unless the anti-terroism act changed this). That is pretty damm public. similar for cell phones. Neither are as well encoded as 802.11 with WEP.
For the most part geeks, nerds, and engenears do not make laws, or intrepret them. Lawyers, ex-lawyers, and judges do. Mostly. As a geek once in a while you might get to advise lawmakers, or even appear before a judge as a witness, but that's pretty much it.
I think you left the visable light part out. And there are laws dealing with that. Mostly that if it is visable from your property or public property you can take a picture of it (unless it is child porn, I asume, or a milatary secret, maybe), but you can't sell the picture for profit in many cases (in others you can). You can look on photo.net for more detail.
That is a good idea since SSH can keep the Bad Thing from happening, while laws can only punish those who did the Bad Thing (and frequently those who are doing a Harmless Thing, at least Harmless To Others).
Plus as far as I know there have been no cases about this, so we don't know how it will turn out.