The only problem with your argument is that the build-out of the network is on government granted easements. Through my property.
If someone else were allowed to string cable (fiber)...
But I wouldn't like it. Enough easements on my property.
As it is, the money made is from the infrastructure, which is already government controlled. And this means equal access.
The cable company cannot allow preferred access, unless it consults me. I was consulted about equal cable access. Adding internet? No, but it happened. And it is fairly equal. Unequal internet?
Meet my friend the backhoe. The penalty for "accidentally" cutting the lines is very minor. Compared to the outage that would happen. Digging without a suitable permit -- maybe a $50 fine (its a misdemeanor). The outage? In this day of VOIP, cable TV, cable internet -- hundreds of customers for a day or so. Think about Superbowl.
There is a big to-do in Alberta, Canada. Where property rights do not include mineral rights (81% mineral rights owned by the government). Which means that the mineral rights are sold separately, and the first the property owner knows is when roads are being built, and an oil pump moves in. Doesn't make for happy ranchers. Ref: http://www.canadianculture.com/geezer/jack06.html
The cable industry? Not an existing "right". Its purely created on the easement for delivery.
I didn't say a thing about open vs. closed source drivers. Indeed, I think that that open source is the way to go.
The purpose of building the DDI is to allow the drivers to be abstracted away from the kernel. This already occurs, but is not an official policy. If the drivers are so abstracted, kernel development can push forward at an accelerated rate.
The reason is simple -- instead of having to check hundreds of drivers against a change, the interface can be checked. As long as the drivers all conform to the interface, they should also work. This makes introduction of new kernel features safer, and allows safer introduction of new drivers as well.
An unintended side effect is that it would be easier to produce binary only drivers. I don't wish to encourage that behaviour, though.
I would like to modify this slightly. I don't think a single DDI (device driver interface) will work, but several DDIs can be defined:
A low level SCSI DDI A low level audio DDI A low level network DDI
and maybe others. Factor the drivers, and extract common parts into the appropriate DDI.
Now, a vendor would write to that DDI, and the Linux team would have to promise that the defined DDI would have a lifespan of (?, but as long as possible). Any drivers needing a custom kernel interface would be planted into the source tree as is now done.
All drivers under the DDI can be checked for conformance. The DDIs would not have to be "officially" introduced until they are ready.
Putting fences like this into the kernel would be (in my opinion) a very good thing.
If a recommended practice is followed, and an "upgrade" breaks it... whose fault is it?
Lets put this into perspective: SUN has (or used to have) the "application guarantee". Basically, if your application runs, and can pass several source analysis tools, it SUNs problem if the application breaks after a system upgrade.
Of course, developers are used to the Microsoft model (if it breaks, you now have two pieces -- and we have nothing to do with it).
The reason that "limited user" operation works on Unix is that most software is ported.
To AIX, Solaris, HP/UX, IRIX, Linux.
It isn't limited to a single user environment (the bigger boxes support many users).
Administrators would have fits if the software required access to priviledged directories and resources, beyond what is vital. That includes NOT writing into your own program directory.
Linux can then leverage from this. The rule is:/usr and/opt should be mountable READ ONLY./bin and/sbin should also be mountable READ ONLY. There are other conventions as well: A system should be bootable and can be maintained WITOUT access to/usr.
Since developers who break these rules get smacked by administrators, the "user account" model "just works".
This is NOT the environment and mindset that Windows comes from.
Given that the plugins do not work at the file format level (at least of the MS formats), but at the level of normal MS Office integration, I would imagine that the plugin will work across most current MS Office versions.
There are plenty of vendors that offer MS Office plugins that work across most versions, and the existence of these plugins is one of the reasons for the "MS Office lock-in". The plugins are NOT offered for other office suites (and this was one of MAs concerns; disability support plugins for MS Office that didn't translate well into other platforms).
The existence of these plugins makes MS Office a platform instead of simply a program. This plugin simply allows continued use of the platform where needed; yet allows competing product and platforms to coexist.
Note that conversion accuracy is no longer a concern:.doc &etc. files will be handled by the NATIVE application, and the ODF format is clearly defined. As long as ODF supports the feature set needed by the plugin (and, given the plugin can be made, it does), which must be reasonably feature complete, things will work.
Now, the plugin layer MUST be (reasonably) feature complete -- simply because if it is NOT, other plugins would suffer badly (eg. screen reader wouldn't be able to determine formatting, thus rendering difficulty to blind users of MS Office).
If you are paranoid about Microsoft, and think that the feature completeness of the plugin layer will or can be compromised -- that is very unlikely. Other plugins would also suffer, and government users would be forced to start looking at alternatives.
The existence of this plugin means that an ecosystem with both Microsoft and alternate vendors can be supported. Which is a good thing. Previously, the only way to use.doc (officially) on many Unix platforms was to use the limited Microsoft viewer. So this is a very good development.
I don't think it will hinder or improve MS Office sales at all, but it will make things possible that have been VERY difficult in the past.
Because nobody builds around MS Office formats. That would be foolish.
What is built around is is COM/DCOM and MS Office components. At which point the underlying representation becomes irrelevant (and can be changed frequently to churn the user base or disrupt competition or introduce new features).
The object interface published (or privately supplied) become the thing that other vendors are beholden to. Supplying speech i/o, integration, reporting, and whatever else. It has to be (relatively) sanctioned by Microsoft, because the hooks at are such a high level. Which makes MS Office a "platform" to base certain kinds of development on.
After all, being able to control Excel as a spreadsheet component directly is much more useful than being able to just write a compatible Excel spreadsheet file. It also provides integration into the platform, and automation.
Indeed a sanctioned way to generating MS Office files is to write a importer in VB Script, and produce the document from that. You need to know NOTHING about the "MS format" to do this.
Good? Bad? I don't know. As an MS shareholder, I find it interesting, though. As a Unix developer, I wish that there were open source CORBA (or whatever) bits to let me move MS systems around to differeent platforms (not in Microsofts interests, so I guess its not happening).
I seriously beg to differ. I would not call people dumb. Disinterested. But the behaviour is the same.
As an example: my sister-in-law (a lawyer, and one of the smartest people I know); who happens to be a hero of mine (having returned to obtain her law degree at the age of 45), who ALSO posesses an RN degree, AND has run a sucessful clothing store (not a franchise), is a computer "idiot".
She needs coaching on many of the basics, and continually seems to pick up stuff like Gator. Along with browser homepage hijacking. The complaint? "It runs slow" or "I can no longer connect". I clean her laptop every 6 months to a year... she considers it a "tuneup", similar to her car.
She is NOT capable of entering a complex URL, and yet prefers Google as her home page (clean, simply, and searching is efficient and effective). My wife, on the other hand, prefers ANOTHER search engine (oriented toward academics, not so clean, but much more relevent to her). My wife will then use Google if the first results don't work (my wife is considerably more "computer savy", and CAN type a URL).
If the next version of IE plants an MSN homepage on her... it will be months before it is replaced with Google. And an "integrated search"? Never. Simply because I won't know or bother. Any MS related issues, WHATEVER they are, are simply accepted as the "cost of buying a Dell" instead of an Apple.
Will MS make more money from this? Sure. Is it bad? Only if MS is leveraging a monopoly. My sister-in-law won't care; frankly, I don't really care either. Google, on the other hand, probably DOES care. Which is why they have raised the issue.
As usual, YMMV. But, please, when I refer to an "average user", I do not mean that they are an idiot, or sub-normal. They may know a BUNCH of stuff that I don't (from gardening to rocket science).
I am not in marketing. This is ENTIRELY my experience. With that it mind, feel free to skip this post...
I have two children: 6 and 8 years of age (bring on the "you can't be a real geek" jokes).
My 6 year old is just getting into some games on the "Nintendo" (N64).
My 8 year old has a Gameboy Advance (bday) and enjoys playing a couple of hours a week.
When my 8 year old saw "Wii", the first question was "Why? that is a strange name. Why?". No, its prounced "Wee". "Like small?, Like PEE? Can we get two of them? Wee Wee?" At which point, she breaks down into a gale of laughter.
At least she isn't pushing for one (however, the pressure is on for a "play station" - Look Dad, they are on sale!).
It reminded me of the time I was working for a chip vendor, who wanted to release the "Copro" series of chips. Get it? "Coprocessed". No one with a classic education in marketing. Went along with "V-Ram" when the ads had upside-down sheep.
You *only* get that accurately if both parties are in the same switching network. The same administrator has end to end control of the network.
If it crosses networks, no such guarantees exist. But, since a positive connection has an "immediate" result, it doesn't matter. Your "busy" or "no connect" signal may, however, be due to any number of reasons (not just that the other party cannot take your call now).
Email, though, is a step away from immediate results. It can be delivered though severly constrained channels, where immediate communication is impossible.
In other words, use the phone (or IM) for immediate communications, with direct connection feedback. Use email for deferred communication. If you need deferral with a "delivery guarantee", use a common server (tools like wiki, or lotus notes).
Good, now that that's out of my system, I'll explain.
Email WITHIN my domain is guaranteed. Honest. If someone (say joe@jupiter.lan) sends mail (to, say, jane@earth.lan), its going through.
If joe@jupiter.lan sends mail to peter@scrape_me.com (whatever), it is rewritten to joe@scrape_this.com, and forwarded to forward_this_shite.net.
After which IT ISN'T MY RESPONSIBILITY. If it can't be forwarded on, it WILL be returned to joe@jupiter.lan. Once accepted, though, I don't care. Not my network. And this makes the world go around.
If there are problems within your LAN or your system, its your responsibility. The original Unix just dropped the mail into the file system. Which is as reliable as the file system. No delivery issues. Linking networks together; as reliable as the linking/forwarding services used.
I can't and won't be responsible for other peoples networking and administration skills.
The guiding principle is "Simple things should be simple. Hard things should be possible".
With closed source software, it is typically "Simple things are taken care of. Hard things are in the next version".
Installing Windows XP is an example. I did not have a system capable of running XP for the longest time. I then decided to build a PVR (personal video recorder). I aquired a suitable motherboard (Athlon 1700+ based), a video tuner card, an AGP card with video out (nVidia 5200FX based), a DVD burner (Memorex) and a fast 120GB disc. The motherboard has ethernet and sound. So far so good.
The motherboard came with an instruction card and it says that "USB 2.0 function can only be obtained with Windows XP". The TV tuner card came with a Windows PVR program. The motherboard comes with a CD with "drivers" for Windows XP (sound, ethernet, and "base").
I put the system together (easy enough, plug A into B, and put the screws in -- a monkey can do this!). I put the Windows XP disc in, and booted. Installed Windows XP.
But... when it came up, it didn't see the optical drive! So, I replaced it with a CD-ROM. Same effect. Reloaded XP, same effect. Loaded Linux (Fedora Core 2) and everything works (including "USB 2.0"). So, I use MythTV.
Later, I learn that the "base" driver is needed -- but I can't get it in the system, because the ethernet doesn't work (and there is no clear instruction, AND the driver doesn't fit on a floppy). The "base" drivers don't fit on a floppy either. Catch-22. So I never bothered.
How is this user-friendly? I would call this "use-torture". Of course, if Windows XP were ALREADY there, it would have been a cake-walk.
Oh, and just to add to the misery: I tried Windows 98. That OS sees the optical drive just fine. But... When I instaled the Windows PVR software, it wouldn't work. Apparently, a "EX_" file wasn't expanded to "EXE" as it should have been (I was curious as to why, so I dug at it). Whats up with that?
I am happy with MythTV, and it works, and the installation instructions actually worked. F/OSS software saved my day.
So, don't fuck with my head, and claim that closed source software (INCLUDING the OS) provides a "better experience". Bullshit.
And, yes, I considered revisting the XP issue -- I imagine I COULD put the drivers on a partition or another hard drive, either using Linux (F/OSS), or, keeping the purist in me happy, ANOTHER SYSTEM, and bootstrapping the OS from that. What I found particularly interesting is that an aquaintance who makes his living fixing Windows boxes told me that the solution to my woes was to boot the box with Knoppix (which, apparently, is now a critical part of his toolkit), and to use that to bring up XP. Knoppix is now a critical piece of Windows repair infrastructure to some.
Usability? Accessibility? Seems to me that it is (almost) completely predicated on Windows XP preloads.
Another example: A thinkpad without a floppy disc, and a CD-ROM. Licensed for Windows 98. The hard drive goes bad. My friend asks me to help. The restore CD is scratched, and doesn't work. Replacement of the CD will take too long (its always an emergency).
My distribution Windows 98 REQUIRES a floppy to boot. And now we have a problem. I end up creating a DOS bootable CD, to bootstrap Windows 98 back onto the system (30 minutes extra). User friendly? Not at all. After all, I *did* give my friend my Windows 98 media kit (and told her to put in the code from her license card). Didn't work, and *I* had to deal with it.
But your Windows (and other closed software experience) may differ.
Just as an aside: I am completely agnostic to platform. I couldn't care less if you use Windows, Linux, Solaris, Apple OS X, or anything else. Whatever turns your crank. I am just pointing out that when the going get difficult for the closed software variants, the shit REALLY hits the fan.
Since network communications can be encrypted and tunneled, simple interception is (generally) pointless. Honestly, I don't know the session keys chosen; I can't help decrypt a lot of the data. Especially an IM session.
So, to implement wiretapping usefully, modifications typically have to be made to each of the endpoint machines (key loggers, etc.). Either additional software, or hardware. Once the endpoint machine modification is in place, what is to prevent it from being used by another agency (not authorized)? Software would be very prone to this, so a hardware solution would be preferred.
Yes, I can see $400 per endpoint machine.
And, being a key logger, it would be very intrusive. Either wiretap data would be sent to custom routers (note that a standard router could be set to block the traffic), adding another expense (but only tapping if specifically authorized) OR the key logger can always log keystrokes to non-volatile memory, to be read out later by an authorized wiretap. In the second case, the user would have to warned about the intrusion ("You are being logged.").
IE cannot be replaced. It must be present. Simply because the help system needs it. In itself, this isn't a problem. Except that MS has achieved a monoply by OS preloads.
Same deal with media players. Not a problem UNLESS a monoply is present, and the purpose of the preload is to obtain another monoply. In this case, its the WMA format.
And, the request made to MS was reasonable: document the links that IE and Media Player have with the rest of the OS.
Now, I believe that MS cannot do this, because the information is simply not available, unless the source is given. In a sense, MS is correct -- these (and other) components are part of the base OS, and can no longer be removed. Such hubris -- MS should have kept documentation to these projects.
Which implies that the either the MS development process is broken, or that MS are really nasty. I tend to believe the first (Mr. Gates is NOT the "devil", but that MS development shoots from the hip).
Still, MS has run afoul of monopoly control laws, in a number of jurisdictions. Why? Not relevant. They must now comply and clean up their act.
Redhat is a monopoly? Apple? Suse? Mandriva? OpenBSD?
These companies HAVE a monoply, and government backing. Specifically, the right to run wires and pipes through MY land. Do I receive fair compensation for this? Yes, IF the company is forced to provide access to all, and charges for the infrastructure.
As an example -- my local Gas supplier does this. My gas bill is split into two parts: one for the infrastructure, the other for the gas itself.
If there is NO fair access, I may get cranky. Backhoe cranky. I can see home renovations coming. And the legislation that I would be breaking? A local misdemeanor, maybe a $50 fine. Not bad that I can disrupt Internet and Phone service to several hundred customers for a measly $50.
Remeber: the "right to property" extends exactely as far as control of the property.
So your contention is that because FLASH 8 and 9 will only be available on INTEL/WINDOWS (maybe MAC OS X) and no other application can possibly "catch up" that ALL home platforms must use INTEL/WINDOWS?
FLASH 7 and 9 are the most important part of the "computing experience" for you?
First, applications ARE available on "alternate" (from your point of view) platforms. Lots of applications. Photo editing, CAD, Office applications. Instant messaging, email and web browsing applications. Gaming, video conferencing, diagraming and project management applications. Financial, programming, and database applications.
Second, there will be a "flash rendering" component available. Start with "gnash".
Third, QEMU will be able to run Intel binaries, where it is otherwise impossible. Indeed, I have used QEMU to run Wine.
The biggest risk item is running nVidia (and other) binary drivers. If the basic i/o with the box is sufficient, then this isn't a concern (for the target audience) either.
The reason that *I* won't be using one of these is that it provides no value proposition for me. But I may rework applications to run on this platform. A potential audience of millions or tens of millions, or, potentially a billion simply cannot be ignored.
Again, this is not a "Wintel" platform; from that perspective it fails. But that is not the target.
Sure, my tv out is done with an nVidia 5200FX card. Cheap, and I can run at 1024x768. No problems on my 42" TV. The only issue is that I run s-video, not composite, and widescreen isn't well supported (4x3 formats only). But its acceptable (given that I don't have access to HD material, SD 4x3 material only).
I have been curious about this design in a shell environment. Do the objects not have serialize to text and generate from text methods?
If this is not supplied, it weakens the "debuggability" of the underlying OOP system. If it is supplied, the methods do not have to be supplied; they are then a standard part. (and I believe that it is -- as witnessed by your recoding of the example).
Given that the domain of the script code is itself text, it makes sense to manipulate at a textual level. The standard posix shell is more concerned with macro expansion than programming and integration concepts.
The object access will then always look a bit kludged (script code will rarely ITSELF be OOP), and any macro facilities will be strange to OOP programmers.
More insight into the "why" of this new shell would be welcome.
MP3 - the patent holder has stated that the only royalties are needed if more than 10,000 units are distributed. This means that Red Hat (for example) does not distribute the codec, but it is legal for you to drop it in later.
DVD - no copyright violation in applying code that plays this on your Linux box. The right (under Copyright, at least in my jurisdiction) is that if it is NECESSARY it is legal. I believe (please correct me) that the DMCA contains a similar clause. This does not give protection for you if a patent infringement claim is made (and I am sure that there are patents involved as well). On the other hand, you could raise the argument that SINCE the DVD was sold to you, an implicit use of the patent was also sold (presuming orthogonality between encoding and decoding).
You have a target number of computations to do in a given period of time. That would the measure of "performance". No matter HOW you slice the computations, they need to flip bits. Each high to low bit flip requires dumping energy. That energy HAS to somewhere, and ends up as heat.
Also, as gates get smaller (which we want, because that allows us to increase speed), leakage increases.
But, if we decouple the computations, and use larger gates (in order to try to decrease the leakage, which is (you guessed) heat), we rapidly end up with the problem of attempting to synchronize the decoupled computations. Which slows stuff down.
One approach is to make computations reversible, and then run them in reverse, thus recovering the energy dumped in the high to low bit flip (because each would have an associated low to high bit flip which would make use of that energy without the need to dump it as heat).
Of course, that doesn't solve the leakage problem (which is arguably the worse of the problems now).
With the GUI, a great deal of the application IS the interface. Note that the interface does NOT scale. If that were the case, many more programmers would be using Java, TCL/Tk, etc.
Case in point: I am writing a simple cheque balancing application. Specifically, it should emulate the "look and feel" of a cheque register. To force the user to focus on a particular line, I am writing code which looks like a magnifying glass on top of the curent focussed line.
Now, the problem. *If* I can presume an advanced 3d rendering engine, I can model the whole thing, and its easy to do. BUT, the software emulation needed is too slow. And there is no easy mapping to a 2d only interface.
*If* I presume that 2d is the way to go, I lose any uniqueness that this application has. Honestly, there are LOTS of cheque balancing programs out there.
So what I am doing is all the interface modeling to 2d calls myself. I can't use dx10, because it isn't there (indeed, most office systems won't have it). And, in this case (as is the case with the OS UI itself) most of the application IS the interface.
As people point out, this makes the Windows experience.
Since applications must gracefully degrade, the advanced UI features cannot form a "platform" (guaranteed available base for deployment). And, since the whole idea of the GUI *is* the UI, its all rather pointless.
Personally, I would be happy if I could guarantee a level of directx support, without having to supply the code (as long as *I* have to bundle it, its really not a platform yet, and until enough people have the necessary hardware, it can't be standard).
Oh well, I just have to do the cheque app the hard way for now...
In 1996, a "top-end" computer would be a Pentium Pro. At 200Mhz.
10 times this would be 2Ghz (and, yes, I am making the mistake of just comparing clock rate, but I don't have much time).
The job of 10 1996 computers can be merged into one computer today (actually, more, but lets stay simple).
Those 10 systems used rack space, power, a/c, etc.
The problem is that if each of those 10 computers had a task (and we presume they did, or they would not have been deployed) and these tasks are combined, you would have a system with 10 times that number of tasks.
Now lets look at an example of a 1996 server: It could handle imapd, httpd, ntpd, tftpd, nfs, smb, dhcpd, yp, sendmail. 9 applications, say 90 processes. After merging, you would have 90 applications, and 900 processes.
A 4 way Operton I just worked with had 1800 processes. Using virtualization, this consolidation can be split back into multiple virtual boxes.
As to the security of virtual machines: I have NEVER had a malicious program in VMWare 4 bring down the entire machine. Easy enough to kill the virtual machine, but the not the host. And I've tried. With proper instruction level support, it will even get better. Old time IBMers have no problem running under VM.
You look forward to exploiting the "3D interface". But you won't be able to. Here's why:
The "home" edition of Vista won't support the interfaces. So, any software oriented toward home use cannot depend on the feature.
Corporate desktops are plain. The investment in the required dx10 infrastructure won't happen for years. So, the feature cannot be exploited in corporate applications either.
After eliminating home and coporate, what is left? AERO really won't have much of a place, outside of enthusiasts. Unless there is an application that can start in the enthusiast domain and drive the migration.
My prediction: the ONLY application that exploits this feature will be Vista itself. Possibly Microsoft may update some applications, but it must remain an optional part.
Microsoft will offer.NET updates and maybe force MS IDE users to use the interface (not as many desktops to migrate, and its a minor part).
Don't count on this feature as a platform for 3 to 5 (or more) years, though.
Slashdot Mirror
In a word, no.
The information is PUBLISHED. Made available. With default controls.
So, the CORRECT analogy would be: A sign on your house that reads "If you have the key, feel free to browse inside".
And, leave the door unlocked, or the key hanging beside the door.
Is THAT trespass?
Ratboy
PS. He IS a nutter, but the charges should be dismissed.
The only problem with your argument is that the build-out of the network is on government granted easements. Through my property.
If someone else were allowed to string cable (fiber)...
But I wouldn't like it. Enough easements on my property.
As it is, the money made is from the infrastructure, which is already government controlled. And this means equal access.
The cable company cannot allow preferred access, unless it consults me. I was consulted about equal cable access. Adding internet? No, but it happened. And it is fairly equal. Unequal internet?
Meet my friend the backhoe. The penalty for "accidentally" cutting the lines is very minor. Compared to the outage that would happen. Digging without a suitable permit -- maybe a $50 fine (its a misdemeanor). The outage? In this day of VOIP, cable TV, cable internet -- hundreds of customers for a day or so. Think about Superbowl.
There is a big to-do in Alberta, Canada. Where property rights do not include mineral rights (81% mineral rights owned by the government). Which means that the mineral rights are sold separately, and the first the property owner knows is when roads are being built, and an oil pump moves in. Doesn't make for happy ranchers. Ref: http://www.canadianculture.com/geezer/jack06.html
The cable industry? Not an existing "right". Its purely created on the easement for delivery.
Ratboy.
I didn't say a thing about open vs. closed source drivers. Indeed, I think that that open source is the way to go.
The purpose of building the DDI is to allow the drivers to be abstracted away from the kernel. This already occurs, but is not an official policy. If the drivers are so abstracted, kernel development can push forward at an accelerated rate.
The reason is simple -- instead of having to check hundreds of drivers against a change, the interface can be checked. As long as the drivers all conform to the interface, they should also work. This makes introduction of new kernel features safer, and allows safer introduction of new drivers as well.
An unintended side effect is that it would be easier to produce binary only drivers. I don't wish to encourage that behaviour, though.
Ratboy.
Thank you.
I would like to modify this slightly. I don't think a single DDI (device driver interface) will work, but several DDIs can be defined:
A low level SCSI DDI
A low level audio DDI
A low level network DDI
and maybe others. Factor the drivers, and extract common parts into the appropriate DDI.
Now, a vendor would write to that DDI, and the Linux team would have to promise that the defined DDI would have a lifespan of (?, but as long as possible). Any drivers needing a custom kernel interface would be planted into the source tree as is now done.
All drivers under the DDI can be checked for conformance. The DDIs would not have to be "officially" introduced until they are ready.
Putting fences like this into the kernel would be (in my opinion) a very good thing.
Ratboy.
If a recommended practice is followed, and an "upgrade" breaks it... whose fault is it?
Lets put this into perspective: SUN has (or used to have) the "application guarantee". Basically, if your application runs, and can pass several source analysis tools, it SUNs problem if the application breaks after a system upgrade.
Of course, developers are used to the Microsoft model (if it breaks, you now have two pieces -- and we have nothing to do with it).
Caveat Emptor
Ratboy
The reason that "limited user" operation works on Unix is that most software is ported.
/usr and /opt should be mountable READ ONLY. /bin and /sbin should also be mountable READ ONLY. There are other conventions as well: A system should be bootable and can be maintained WITOUT access to /usr.
To AIX, Solaris, HP/UX, IRIX, Linux.
It isn't limited to a single user environment (the bigger boxes support many users).
Administrators would have fits if the software required access to priviledged directories and resources, beyond what is vital. That includes NOT writing into your own program directory.
Linux can then leverage from this. The rule is:
Since developers who break these rules get smacked by administrators, the "user account" model "just works".
This is NOT the environment and mindset that Windows comes from.
Ratboy
Given that the plugins do not work at the file format level (at least of the MS formats), but at the level of normal MS Office integration, I would imagine that the plugin will work across most current MS Office versions.
.doc &etc. files will be handled by the NATIVE application, and the ODF format is clearly defined. As long as ODF supports the feature set needed by the plugin (and, given the plugin can be made, it does), which must be reasonably feature complete, things will work.
.doc (officially) on many Unix platforms was to use the limited Microsoft viewer. So this is a very good development.
There are plenty of vendors that offer MS Office plugins that work across most versions, and the existence of these plugins is one of the reasons for the "MS Office lock-in". The plugins are NOT offered for other office suites (and this was one of MAs concerns; disability support plugins for MS Office that didn't translate well into other platforms).
The existence of these plugins makes MS Office a platform instead of simply a program. This plugin simply allows continued use of the platform where needed; yet allows competing product and platforms to coexist.
Note that conversion accuracy is no longer a concern:
Now, the plugin layer MUST be (reasonably) feature complete -- simply because if it is NOT, other plugins would suffer badly (eg. screen reader wouldn't be able to determine formatting, thus rendering difficulty to blind users of MS Office).
If you are paranoid about Microsoft, and think that the feature completeness of the plugin layer will or can be compromised -- that is very unlikely. Other plugins would also suffer, and government users would be forced to start looking at alternatives.
The existence of this plugin means that an ecosystem with both Microsoft and alternate vendors can be supported. Which is a good thing. Previously, the only way to use
I don't think it will hinder or improve MS Office sales at all, but it will make things possible that have been VERY difficult in the past.
I will start seeding the plugin as soon as I can!
Ratboy
Because nobody builds around MS Office formats. That would be foolish.
What is built around is is COM/DCOM and MS Office components. At which point the underlying representation becomes irrelevant (and can be changed frequently to churn the user base or disrupt competition or introduce new features).
The object interface published (or privately supplied) become the thing that other vendors are beholden to. Supplying speech i/o, integration, reporting, and whatever else. It has to be (relatively) sanctioned by Microsoft, because the hooks at are such a high level. Which makes MS Office a "platform" to base certain kinds of development on.
After all, being able to control Excel as a spreadsheet component directly is much more useful than being able to just write a compatible Excel spreadsheet file. It also provides integration into the platform, and automation.
Indeed a sanctioned way to generating MS Office files is to write a importer in VB Script, and produce the document from that. You need to know NOTHING about the "MS format" to do this.
Good? Bad? I don't know. As an MS shareholder, I find it interesting, though. As a Unix developer, I wish that there were open source CORBA (or whatever) bits to let me move MS systems around to differeent platforms (not in Microsofts interests, so I guess its not happening).
As usual, YMMV.
Ratboy.
begin_rant
I seriously beg to differ. I would not call people dumb. Disinterested. But the behaviour is the same.
As an example: my sister-in-law (a lawyer, and one of the smartest people I know); who happens to be a hero of mine (having returned to obtain her law degree at the age of 45), who ALSO posesses an RN degree, AND has run a sucessful clothing store (not a franchise), is a computer "idiot".
She needs coaching on many of the basics, and continually seems to pick up stuff like Gator. Along with browser homepage hijacking. The complaint? "It runs slow" or "I can no longer connect". I clean her laptop every 6 months to a year... she considers it a "tuneup", similar to her car.
She is NOT capable of entering a complex URL, and yet prefers Google as her home page (clean, simply, and searching is efficient and effective). My wife, on the other hand, prefers ANOTHER search engine (oriented toward academics, not so clean, but much more relevent to her). My wife will then use Google if the first results don't work (my wife is considerably more "computer savy", and CAN type a URL).
If the next version of IE plants an MSN homepage on her... it will be months before it is replaced with Google. And an "integrated search"? Never. Simply because I won't know or bother. Any MS related issues, WHATEVER they are, are simply accepted as the "cost of buying a Dell" instead of an Apple.
Will MS make more money from this? Sure. Is it bad? Only if MS is leveraging a monopoly. My sister-in-law won't care; frankly, I don't really care either. Google, on the other hand, probably DOES care. Which is why they have raised the issue.
As usual, YMMV. But, please, when I refer to an "average user", I do not mean that they are an idiot, or sub-normal. They may know a BUNCH of stuff that I don't (from gardening to rocket science).
end_rant
Ratboy
I am not in marketing. This is ENTIRELY my experience. With that it mind, feel free to skip this post...
I have two children: 6 and 8 years of age (bring on the "you can't be a real geek" jokes).
My 6 year old is just getting into some games on the "Nintendo" (N64).
My 8 year old has a Gameboy Advance (bday) and enjoys playing a couple of hours a week.
When my 8 year old saw "Wii", the first question was "Why? that is a strange name. Why?". No, its prounced "Wee". "Like small?, Like PEE? Can we get two of them? Wee Wee?" At which point, she breaks down into a gale of laughter.
At least she isn't pushing for one (however, the pressure is on for a "play station" - Look Dad, they are on sale!).
It reminded me of the time I was working for a chip vendor, who wanted to release the "Copro" series of chips. Get it? "Coprocessed". No one with a classic education in marketing. Went along with "V-Ram" when the ads had upside-down sheep.
Plus ça change...
Ratboy
You *only* get that accurately if both parties are in the same switching network. The same administrator has end to end control of the network.
If it crosses networks, no such guarantees exist. But, since a positive connection has an "immediate" result, it doesn't matter. Your "busy" or "no connect" signal may, however, be due to any number of reasons (not just that the other party cannot take your call now).
Email, though, is a step away from immediate results. It can be delivered though severly constrained channels, where immediate communication is impossible.
In other words, use the phone (or IM) for immediate communications, with direct connection feedback. Use email for deferred communication. If you need deferral with a "delivery guarantee", use a common server (tools like wiki, or lotus notes).
Ratboy.
Crap. Crap. Crap.
Good, now that that's out of my system, I'll explain.
Email WITHIN my domain is guaranteed. Honest. If someone (say joe@jupiter.lan) sends mail (to, say, jane@earth.lan), its going through.
If joe@jupiter.lan sends mail to peter@scrape_me.com (whatever), it is rewritten to joe@scrape_this.com, and forwarded to forward_this_shite.net.
After which IT ISN'T MY RESPONSIBILITY. If it can't be forwarded on, it WILL be returned to joe@jupiter.lan. Once accepted, though, I don't care. Not my network. And this makes the world go around.
If there are problems within your LAN or your system, its your responsibility. The original Unix just dropped the mail into the file system. Which is as reliable as the file system. No delivery issues. Linking networks together; as reliable as the linking/forwarding services used.
I can't and won't be responsible for other peoples networking and administration skills.
Ratboy
The guiding principle is "Simple things should be simple. Hard things should be possible".
With closed source software, it is typically "Simple things are taken care of. Hard things are in the next version".
Installing Windows XP is an example. I did not have a system capable of running XP for the longest time. I then decided to build a PVR (personal video recorder). I aquired a suitable motherboard (Athlon 1700+ based), a video tuner card, an AGP card with video out (nVidia 5200FX based), a DVD burner (Memorex) and a fast 120GB disc. The motherboard has ethernet and sound. So far so good.
The motherboard came with an instruction card and it says that "USB 2.0 function can only be obtained with Windows XP". The TV tuner card came with a Windows PVR program. The motherboard comes with a CD with "drivers" for Windows XP (sound, ethernet, and "base").
I put the system together (easy enough, plug A into B, and put the screws in -- a monkey can do this!). I put the Windows XP disc in, and booted. Installed Windows XP.
But... when it came up, it didn't see the optical drive! So, I replaced it with a CD-ROM. Same effect. Reloaded XP, same effect. Loaded Linux (Fedora Core 2) and everything works (including "USB 2.0"). So, I use MythTV.
Later, I learn that the "base" driver is needed -- but I can't get it in the system, because the ethernet doesn't work (and there is no clear instruction, AND the driver doesn't fit on a floppy). The "base" drivers don't fit on a floppy either. Catch-22. So I never bothered.
How is this user-friendly? I would call this "use-torture". Of course, if Windows XP were ALREADY there, it would have been a cake-walk.
Oh, and just to add to the misery: I tried Windows 98. That OS sees the optical drive just fine. But... When I instaled the Windows PVR software, it wouldn't work. Apparently, a "EX_" file wasn't expanded to "EXE" as it should have been (I was curious as to why, so I dug at it). Whats up with that?
I am happy with MythTV, and it works, and the installation instructions actually worked. F/OSS software saved my day.
So, don't fuck with my head, and claim that closed source software (INCLUDING the OS) provides a "better experience". Bullshit.
And, yes, I considered revisting the XP issue -- I imagine I COULD put the drivers on a partition or another hard drive, either using Linux (F/OSS), or, keeping the purist in me happy, ANOTHER SYSTEM, and bootstrapping the OS from that. What I found particularly interesting is that an aquaintance who makes his living fixing Windows boxes told me that the solution to my woes was to boot the box with Knoppix (which, apparently, is now a critical part of his toolkit), and to use that to bring up XP. Knoppix is now a critical piece of Windows repair infrastructure to some.
Usability? Accessibility? Seems to me that it is (almost) completely predicated on Windows XP preloads.
Another example: A thinkpad without a floppy disc, and a CD-ROM. Licensed for Windows 98. The hard drive goes bad. My friend asks me to help. The restore CD is scratched, and doesn't work. Replacement of the CD will take too long (its always an emergency).
My distribution Windows 98 REQUIRES a floppy to boot. And now we have a problem. I end up creating a DOS bootable CD, to bootstrap Windows 98 back onto the system (30 minutes extra). User friendly? Not at all. After all, I *did* give my friend my Windows 98 media kit (and told her to put in the code from her license card). Didn't work, and *I* had to deal with it.
But your Windows (and other closed software experience) may differ.
Just as an aside: I am completely agnostic to platform. I couldn't care less if you use Windows, Linux, Solaris, Apple OS X, or anything else. Whatever turns your crank. I am just pointing out that when the going get difficult for the closed software variants, the shit REALLY hits the fan.
Your mileage, however, may vary.
Ratboy.
Since network communications can be encrypted and tunneled, simple interception is (generally) pointless. Honestly, I don't know the session keys chosen; I can't help decrypt a lot of the data. Especially an IM session.
So, to implement wiretapping usefully, modifications typically have to be made to each of the endpoint machines (key loggers, etc.). Either additional software, or hardware. Once the endpoint machine modification is in place, what is to prevent it from being used by another agency (not authorized)? Software would be very prone to this, so a hardware solution would be preferred.
Yes, I can see $400 per endpoint machine.
And, being a key logger, it would be very intrusive. Either wiretap data would be sent to custom routers (note that a standard router could be set to block the traffic), adding another expense (but only tapping if specifically authorized) OR the key logger can always log keystrokes to non-volatile memory, to be read out later by an authorized wiretap. In the second case, the user would have to warned about the intrusion ("You are being logged.").
What a fuck-up.
Ratboy.
IE cannot be replaced. It must be present. Simply because the help system needs it. In itself, this isn't a problem. Except that MS has achieved a monoply by OS preloads.
Same deal with media players. Not a problem UNLESS a monoply is present, and the purpose of the preload is to obtain another monoply. In this case, its the WMA format.
And, the request made to MS was reasonable: document the links that IE and Media Player have with the rest of the OS.
Now, I believe that MS cannot do this, because the information is simply not available, unless the source is given. In a sense, MS is correct -- these (and other) components are part of the base OS, and can no longer be removed. Such hubris -- MS should have kept documentation to these projects.
Which implies that the either the MS development process is broken, or that MS are really nasty. I tend to believe the first (Mr. Gates is NOT the "devil", but that MS development shoots from the hip).
Still, MS has run afoul of monopoly control laws, in a number of jurisdictions. Why? Not relevant. They must now comply and clean up their act.
Redhat is a monopoly? Apple? Suse? Mandriva? OpenBSD?
Ratboy.
These companies HAVE a monoply, and government backing. Specifically, the right to run wires and pipes through MY land. Do I receive fair compensation for this? Yes, IF the company is forced to provide access to all, and charges for the infrastructure.
As an example -- my local Gas supplier does this. My gas bill is split into two parts: one for the infrastructure, the other for the gas itself.
If there is NO fair access, I may get cranky. Backhoe cranky. I can see home renovations coming. And the legislation that I would be breaking? A local misdemeanor, maybe a $50 fine. Not bad that I can disrupt Internet and Phone service to several hundred customers for a measly $50.
Remeber: the "right to property" extends exactely as far as control of the property.
Ratboy
So your contention is that because FLASH 8 and 9 will only be available on INTEL/WINDOWS (maybe MAC OS X) and no other application can possibly "catch up" that ALL home platforms must use INTEL/WINDOWS?
FLASH 7 and 9 are the most important part of the "computing experience" for you?
Ratboy
Why is this a problem?
First, applications ARE available on "alternate" (from your point of view) platforms. Lots of applications. Photo editing, CAD, Office applications. Instant messaging, email and web browsing applications. Gaming, video conferencing, diagraming and project management applications. Financial, programming, and database applications.
Second, there will be a "flash rendering" component available. Start with "gnash".
Third, QEMU will be able to run Intel binaries, where it is otherwise impossible. Indeed, I have used QEMU to run Wine.
The biggest risk item is running nVidia (and other) binary drivers. If the basic i/o with the box is sufficient, then this isn't a concern (for the target audience) either.
The reason that *I* won't be using one of these is that it provides no value proposition for me. But I may rework applications to run on this platform. A potential audience of millions or tens of millions, or, potentially a billion simply cannot be ignored.
Again, this is not a "Wintel" platform; from that perspective it fails. But that is not the target.
Ratboy
Sure, my tv out is done with an nVidia 5200FX card. Cheap, and I can run at 1024x768. No problems on my 42" TV. The only issue is that I run s-video, not composite, and widescreen isn't well supported (4x3 formats only). But its acceptable (given that I don't have access to HD material, SD 4x3 material only).
Ratboy
Bruce
I have been curious about this design in a shell environment. Do the objects not have serialize to text and generate from text methods?
If this is not supplied, it weakens the "debuggability" of the underlying OOP system. If it is supplied, the methods do not have to be supplied; they are then a standard part. (and I believe that it is -- as witnessed by your recoding of the example).
Given that the domain of the script code is itself text, it makes sense to manipulate at a textual level. The standard posix shell is more concerned with macro expansion than programming and integration concepts.
The object access will then always look a bit kludged (script code will rarely ITSELF be OOP), and any macro facilities will be strange to OOP programmers.
More insight into the "why" of this new shell would be welcome.
Ratboy
MP3 - the patent holder has stated that the only royalties are needed if more than 10,000 units are distributed. This means that Red Hat (for example) does not distribute the codec, but it is legal for you to drop it in later.
DVD - no copyright violation in applying code that plays this on your Linux box. The right (under Copyright, at least in my jurisdiction) is that if it is NECESSARY it is legal. I believe (please correct me) that the DMCA contains a similar clause. This does not give protection for you if a patent infringement claim is made (and I am sure that there are patents involved as well). On the other hand, you could raise the argument that SINCE the DVD was sold to you, an implicit use of the patent was also sold (presuming orthogonality between encoding and decoding).
Ratboy
Won't work. Here's why.
You have a target number of computations to do in a given period of time. That would the measure of "performance". No matter HOW you slice the computations, they need to flip bits. Each high to low bit flip requires dumping energy. That energy HAS to somewhere, and ends up as heat.
Also, as gates get smaller (which we want, because that allows us to increase speed), leakage increases.
But, if we decouple the computations, and use larger gates (in order to try to decrease the leakage, which is (you guessed) heat), we rapidly end up with the problem of attempting to synchronize the decoupled computations. Which slows stuff down.
One approach is to make computations reversible, and then run them in reverse, thus recovering the energy dumped in the high to low bit flip (because each would have an associated low to high bit flip which would make use of that energy without the need to dump it as heat).
Of course, that doesn't solve the leakage problem (which is arguably the worse of the problems now).
Ratboy
With the GUI, a great deal of the application IS the interface. Note that the interface does NOT scale. If that were the case, many more programmers would be using Java, TCL/Tk, etc.
Case in point: I am writing a simple cheque balancing application. Specifically, it should emulate the "look and feel" of a cheque register. To force the user to focus on a particular line, I am writing code which looks like a magnifying glass on top of the curent focussed line.
Now, the problem. *If* I can presume an advanced 3d rendering engine, I can model the whole thing, and its easy to do. BUT, the software emulation needed is too slow. And there is no easy mapping to a 2d only interface.
*If* I presume that 2d is the way to go, I lose any uniqueness that this application has. Honestly, there are LOTS of cheque balancing programs out there.
So what I am doing is all the interface modeling to 2d calls myself. I can't use dx10, because it isn't there (indeed, most office systems won't have it). And, in this case (as is the case with the OS UI itself) most of the application IS the interface.
As people point out, this makes the Windows experience.
Since applications must gracefully degrade, the advanced UI features cannot form a "platform" (guaranteed available base for deployment). And, since the whole idea of the GUI *is* the UI, its all rather pointless.
Personally, I would be happy if I could guarantee a level of directx support, without having to supply the code (as long as *I* have to bundle it, its really not a platform yet, and until enough people have the necessary hardware, it can't be standard).
Oh well, I just have to do the cheque app the hard way for now...
Ratboy.
Computers are more powerful now than then.
In 1996, a "top-end" computer would be a Pentium Pro. At 200Mhz.
10 times this would be 2Ghz (and, yes, I am making the mistake of just comparing clock rate, but I don't have much time).
The job of 10 1996 computers can be merged into one computer today (actually, more, but lets stay simple).
Those 10 systems used rack space, power, a/c, etc.
The problem is that if each of those 10 computers had a task (and we presume they did, or they would not have been deployed) and these tasks are combined, you would have a system with 10 times that number of tasks.
Now lets look at an example of a 1996 server: It could handle imapd, httpd, ntpd, tftpd, nfs, smb, dhcpd, yp, sendmail. 9 applications, say 90 processes. After merging, you would have 90 applications, and 900 processes.
A 4 way Operton I just worked with had 1800 processes. Using virtualization, this consolidation can be split back into multiple virtual boxes.
As to the security of virtual machines: I have NEVER had a malicious program in VMWare 4 bring down the entire machine. Easy enough to kill the virtual machine, but the not the host. And I've tried. With proper instruction level support, it will even get better. Old time IBMers have no problem running under VM.
Ratboy666
You look forward to exploiting the "3D interface". But you won't be able to. Here's why:
.NET updates and maybe force MS IDE users to use the interface (not as many desktops to migrate, and its a minor part).
The "home" edition of Vista won't support the interfaces. So, any software oriented toward home use cannot depend on the feature.
Corporate desktops are plain. The investment in the required dx10 infrastructure won't happen for years. So, the feature cannot be exploited in corporate applications either.
After eliminating home and coporate, what is left? AERO really won't have much of a place, outside of enthusiasts. Unless there is an application that can start in the enthusiast domain and drive the migration.
My prediction: the ONLY application that exploits this feature will be Vista itself. Possibly Microsoft may update some applications, but it must remain an optional part.
Microsoft will offer
Don't count on this feature as a platform for 3 to 5 (or more) years, though.
Ratboy.