On the powerbook you can concurrently have different resolutions on the built in display and the external monitor. I'm typing this right now on a 12" power book with an external 17" display with the internal screen at 1024x768 and the external screen at 1280 x 1024. I've had an external display running at 1600 x 1200 as well, but it was only a 17" screen, and it was doing my eyes in...
Ermmm, Apple are a computer hardware manufacturer. Microsoft's share of this market is ~= 0% (as it includes only mice and keyboards). Apple's share is considerably higher than Microsoft's;-)
If you are looking at the OS market, then you are right, Apple would love to be the dominant player, but only because of all the extra hardware they would sell;-)
I don't believe Apple would have a chance of getting to be the majority OS vendor in the x86 computer market, because firstly they don't currently have the resources to be able to maintain their software quality on the huge mess that is the x86 platform, and secondly, if they went for that market Microsoft would just refuse to license Windows to manufacturers that installed Apple's OS on their machines, so there is no path to market.
Of course, that's a circular argument - if Apple had licensed their OS before Windows existed (which they probably had the opportunity to do), then they would likely be the majority OS vendor now. At the time, though, there wasn't an established business model for bing able to make money from an OS in existence. One of Microsoft's biggest innovations was coming up with a way (albeit unethical and illegal) to make money in this market.
I would have to disagree with you when you say that almost no-one can distinguish between 128K and the original CDs. On any reasonable sound system, almost everyone I know can tell the difference at this level.
By reasonable sound system, I don't mean some kind of high priced audiophile equipment. If you are listening in a moving car with the windows open, then maybe most people wouldn't notice the different.
If you genuinely can't tell the difference, then you have my sympathy for your poor hearing.
On the other hand, using 112kbps to pack in more songs is a great compromise if it works for you. After all, the quality of the music is much more important than the quality of the sound.
I don't like to carry my Marshall head from gig to gig, but I do like to have it at the gig, so there isn't really much alternative...;-)
More to the point, if you're toting a Marshall head then you are probably also carrying at least 1 4x12 speaker cabinet, which makes even the head feel portable.
While I agree that IE will continue to hold the lion's share of the Windows browser market due to its built-in status, I have to take issue with the idea that not even knowledgable people want to download a new browser.
You can certainly take issue with whether I am a knowledgable person (I think so, but I could be biased;-), but I would have to say that I wouldn't want to download a browser unless I was going to be forced to use IE, in which case I would happily download any alternative, even the whole Mozilla suite on a dialup connection.
(On a slightly more serious note, anyone doing web development will appreciate the better tools in Mozilla, and is likely to have a whole slew of other browsers installed for test purposes.)
Just to be picky, the sizes can make a difference. Firstly, there is no such thing as a standard TCP packet size - packetization of TCP messages is done at the link layer, so the packet size will depend on the technologies used in the various links it is hopping across. For example, there is room and to spare in an Ethernet frame, but if the data is going across an ATM network the cell size is going to be 49 bytes. Of course if the traffic is traversing an ATM network then it is likely fast enough that this will be an entirely negligible effect.
More significant is the time taken to actually transfer the data across a slow (e.g. modem) link. Sure, even with a 28.8 modem 50 bytes is a small fraction of a second, but those can add up. If a page uses the same spacer GIF for all spacers then it should get downloaded once and cached, but if the page is coded to use custom spacers for design reasons then the delay over a modem link can be measurable.
I do basically agree with you though, that for any sanely designed web page, today's communication speeds are such that a saving on the size of spacer images makes no difference.
I mean shit, if you'd have started "The Firewire Group" as an off-shoot of the IEEE1394 working group, you'd probably be selling more iPods because I could use them as storage for my Sony DV Recorder. By the same token, if you ever want Rendevous to be at all useful to people in the real world, it has to be cross-platform. So either submit it to a standards body, or better yet, make "The Rendevous Group" and licence it out.
As I understand it, Firewire is just Apple's branded implementation of the open IEEE1394 standard. This is why everybody's DV cameras can be hooked up to computers (albeit with some variations in the physical connectors).
Similarly, Rendezvous is Apple's branded implementation of the ZEROCONF standards published by the IETF, and should therefore interwork with other implementations once the other OS vendors get off their backside and implement them.
I don't necessarily agree with Apple's position on this one, but I think your criticisms here are factually incorrect.
As far as I remember (and it's a long time ago) you could do indexed jumps using the X register as an offset into the zero page. I seem to remember the BBC OS making extensive use of this...
(For the geographically challenged (e.g. Americans;-) the BBC was a popular 8 bit microcomputer in the UK, which was put together by Acorn and won the bid to be used as the computer for a BBC TV educational series on what computers were and what you could do with them...
Naw - it had way too many registers. Who needs more than three?;-)
The Z80 had lots of clever bits you could fiddle around with, but the 6502 is the most elegantly designed CPU (from the programmer's perspective) I have ever worked with.
I guess they both appealed to different sets of people...
On OS X I right click on the icon (or control click if you are still running a one button mouse) for a running app in the dock and I get a menu including an item for each open window.
I use windows a lot, and I always end up with more icons that fit in the bar and end up having to page through them. The dock way feels easier to me...
I don't want to bash Microsoft here, particularly as the last version of Microsoft C++ that I used professionally was 5.x, which was a long time ago.
However, to my knowledge, Microsoft have never had the fastest compiling compiler, the compiler producing the fastest code, the most standards compliant compiler, or the compiler most reliably compiling code to a binary version which does what the source says. At various points they have been last in each of these categories. (I have particularly vivid memories of the nonsense it spewed out in the guise of executable code if you forgot to provide the compiler flag to disable the unsafe optimizations.)
The one category that Microsoft have definitely come top in is support for Windows (MFC etc.) I suppose this category would also include not being broken by the latest Windows upgrade, which is a fate that seemed to befall many other vendor's compilers.
It would be much more surprising that Microsoft's C++ compiler came top in a category than that Intel (knowing the chip is a much bigger benefit to compiler writing than knowing the OS) produced a better compiler for Intel chips.
...and a good CLI environment will beat bad GUI tools.
Of course, it depends exactly where you draw the line. Emacs, for instance, is a GUI tool by my definition (e.g. it has menus), but it has been referred to in this thread as a CLI tool. Even vi is somewhere inbetween (surely a CLI purist would use a line editor like ex;-)
I really don't think many people would argue that visual editors and graphical debuggers haven't improved productivity. I've used purify with and without a GUI, and with is better.
For IDE's, I think it is less clear cut. For projects that fall into the shape the IDE designers envisaged they can be quite cool, but command line tools have wider boundaries and are easier to extend (e.g. incorporating your own script based code generation tools into the project build systems.
Finally, tools that offer both options generally allow you to choose the right tool for the job - I still want to be able to type debugging commands in at the command line in my graphical debugger.
Slashdot Mirror
On the powerbook you can concurrently have different resolutions on the built in display and the external monitor. I'm typing this right now on a 12" power book with an external 17" display with the internal screen at 1024x768 and the external screen at 1280 x 1024. I've had an external display running at 1600 x 1200 as well, but it was only a 17" screen, and it was doing my eyes in...
Ermmm, Apple are a computer hardware manufacturer. Microsoft's share of this market is ~= 0% (as it includes only mice and keyboards). Apple's share is considerably higher than Microsoft's ;-)
;-)
If you are looking at the OS market, then you are right, Apple would love to be the dominant player, but only because of all the extra hardware they would sell
I don't believe Apple would have a chance of getting to be the majority OS vendor in the x86 computer market, because firstly they don't currently have the resources to be able to maintain their software quality on the huge mess that is the x86 platform, and secondly, if they went for that market Microsoft would just refuse to license Windows to manufacturers that installed Apple's OS on their machines, so there is no path to market.
Of course, that's a circular argument - if Apple had licensed their OS before Windows existed (which they probably had the opportunity to do), then they would likely be the majority OS vendor now. At the time, though, there wasn't an established business model for bing able to make money from an OS in existence. One of Microsoft's biggest innovations was coming up with a way (albeit unethical and illegal) to make money in this market.
I would have to disagree with you when you say that almost no-one can distinguish between 128K and the original CDs. On any reasonable sound system, almost everyone I know can tell the difference at this level.
By reasonable sound system, I don't mean some kind of high priced audiophile equipment. If you are listening in a moving car with the windows open, then maybe most people wouldn't notice the different.
If you genuinely can't tell the difference, then you have my sympathy for your poor hearing.
On the other hand, using 112kbps to pack in more songs is a great compromise if it works for you. After all, the quality of the music is much more important than the quality of the sound.
I don't like to carry my Marshall head from gig to gig, but I do like to have it at the gig, so there isn't really much alternative... ;-)
More to the point, if you're toting a Marshall head then you are probably also carrying at least 1 4x12 speaker cabinet, which makes even the head feel portable.
While I agree that IE will continue to hold the lion's share of the Windows browser market due to its built-in status, I have to take issue with the idea that not even knowledgable people want to download a new browser.
;-), but I would have to say that I wouldn't want to download a browser unless I was going to be forced to use IE, in which case I would happily download any alternative, even the whole Mozilla suite on a dialup connection.
You can certainly take issue with whether I am a knowledgable person (I think so, but I could be biased
(On a slightly more serious note, anyone doing web development will appreciate the better tools in Mozilla, and is likely to have a whole slew of other browsers installed for test purposes.)
Just to be picky, the sizes can make a difference. Firstly, there is no such thing as a standard TCP packet size - packetization of TCP messages is done at the link layer, so the packet size will depend on the technologies used in the various links it is hopping across. For example, there is room and to spare in an Ethernet frame, but if the data is going across an ATM network the cell size is going to be 49 bytes. Of course if the traffic is traversing an ATM network then it is likely fast enough that this will be an entirely negligible effect.
More significant is the time taken to actually transfer the data across a slow (e.g. modem) link. Sure, even with a 28.8 modem 50 bytes is a small fraction of a second, but those can add up. If a page uses the same spacer GIF for all spacers then it should get downloaded once and cached, but if the page is coded to use custom spacers for design reasons then the delay over a modem link can be measurable.
I do basically agree with you though, that for any sanely designed web page, today's communication speeds are such that a saving on the size of spacer images makes no difference.
As I understand it, Firewire is just Apple's branded implementation of the open IEEE1394 standard. This is why everybody's DV cameras can be hooked up to computers (albeit with some variations in the physical connectors).
Similarly, Rendezvous is Apple's branded implementation of the ZEROCONF standards published by the IETF, and should therefore interwork with other implementations once the other OS vendors get off their backside and implement them.
I don't necessarily agree with Apple's position on this one, but I think your criticisms here are factually incorrect.
As far as I remember (and it's a long time ago) you could do indexed jumps using the X register as an offset into the zero page. I seem to remember the BBC OS making extensive use of this...
;-) the BBC was a popular 8 bit microcomputer in the UK, which was put together by Acorn and won the bid to be used as the computer for a BBC TV educational series on what computers were and what you could do with them...
(For the geographically challenged (e.g. Americans
Naw - it had way too many registers. Who needs more than three? ;-)
The Z80 had lots of clever bits you could fiddle around with, but the 6502 is the most elegantly designed CPU (from the programmer's perspective) I have ever worked with.
I guess they both appealed to different sets of people...
Am I missing something?
On OS X I right click on the icon (or control click if you are still running a one button mouse) for a running app in the dock and I get a menu including an item for each open window.
I use windows a lot, and I always end up with more icons that fit in the bar and end up having to page through them. The dock way feels easier to me...
I don't want to bash Microsoft here, particularly as the last version of Microsoft C++ that I used professionally was 5.x, which was a long time ago.
However, to my knowledge, Microsoft have never had the fastest compiling compiler, the compiler producing the fastest code, the most standards compliant compiler, or the compiler most reliably compiling code to a binary version which does what the source says. At various points they have been last in each of these categories. (I have particularly vivid memories of the nonsense it spewed out in the guise of executable code if you forgot to provide the compiler flag to disable the unsafe optimizations.)
The one category that Microsoft have definitely come top in is support for Windows (MFC etc.) I suppose this category would also include not being broken by the latest Windows upgrade, which is a fate that seemed to befall many other vendor's compilers.
It would be much more surprising that Microsoft's C++ compiler came top in a category than that Intel (knowing the chip is a much bigger benefit to compiler writing than knowing the OS) produced a better compiler for Intel chips.
All IMHO of course, and YMMV.
...and a good CLI environment will beat bad GUI tools.
;-)
Of course, it depends exactly where you draw the line. Emacs, for instance, is a GUI tool by my definition (e.g. it has menus), but it has been referred to in this thread as a CLI tool. Even vi is somewhere inbetween (surely a CLI purist would use a line editor like ex
I really don't think many people would argue that visual editors and graphical debuggers haven't improved productivity. I've used purify with and without a GUI, and with is better.
For IDE's, I think it is less clear cut. For projects that fall into the shape the IDE designers envisaged they can be quite cool, but command line tools have wider boundaries and are easier to extend (e.g. incorporating your own script based code generation tools into the project build systems.
Finally, tools that offer both options generally allow you to choose the right tool for the job - I still want to be able to type debugging commands in at the command line in my graphical debugger.