Crufty old proprietary, 20 years ago? I'll give you proprietary, but a lot of technological advancement goes on in the unix world. Unless Solaris, AIX, and HP-UX are non-existant. And let's not forget about the huge entrenched VMS userbase....
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
i wouldn't be so sure about that - my floppy copies of MacOS 6 and 7 worked well on my classics and such. even my powerbook 140, and this was only 5-6 years ago. worked perfectly, original factory disk sets.
anyway, for the curious, a rundown on writing old mac floppies.
(note: if you do them as 1.44MB floppies, they read/write at the same speed, so no special hardware needed as long as you have macs that can read 1.44s. easy way to avoid the hassle if you have the option.)
Never released, YES.
Never shown and proven to be working alibet slowly and inefficiently? FALSE.
WinHEC 2003 developers saw, recieved first hand, and got to work with longhorn alphas that showed WORKING WinFS (as slow and inefficient as it was, it did what was described). Not vaporware, they actually proved it. then realized that, at the time, with computer power and legacy trappings, at the time, they couldn't deliver. Along with a
Shit happens, but it wasn't vapor ware. it was delivered to developers, shown, proven, and canceled. That's a far sight different than vaporware (shown/faked, but never proven or letting developers have the bits.)
Re the others mentioning WinFS:
The tech demos were not "pre-rendered" -
You can find longhorn alphas floating around with WinFS implementations that perform as described (alibet slowly).
They will work as described in the docs.
That I had alpha bits in my hands?
That I could develop for, link against, compile against, and work with?
That blew my mind when the whole project was scrapped?
THAT -worked- in longhorn alphas?!
I don't consider that vaporware - they delivered bits. It worked, it was horrendously slow and inefficient due to legacy trappings - but WinFS worked to it's design specs.
"Not to mention its as much vaporware as the 2002 DNF demo. What he is talking about is the Longhorn tech demo which showed off a metadata based file system called WinFS but we don't know how it actually ran because it was never released. Every. single. thing. we know about how WinFS supposedly "worked" is based on MSFT tech demos which frankly could have been pre-rendered BS for all we know and what they showed off in 2004 as WinFS never ended up in the hands of the public."
That's the only statement in your entire comment I take exception with. It wasn't pre-rendered demos, it wasn't BS, it was bits we acquired and worked with. Bits that actually did what was described. Bits that actually did what was in the *hardcopy* developer manuals I was given at WinHEC. ReFS is now, I believe, a beginning to re-implement WinFS in an achivable timeframe, without huge overhead, and without extolling insane goals beforehand without any idea of how the development process will go. While they may have scrapped the initial WinFS, the idea still lives on. Libraries live on in a basic form, ReFS is some core principals outlined in my WinFS dev guides (not the relational aspects, but some architecture sides that'll make the relational parts possible!)
So, yes, it was never "released", yet, it was in developer hands and was shown to work, even if horribly inefficiently, it
Really? I've installed Win8 hundreds of times across VMs, bare metal, etc, and not ONCE has it mentioned secure boot to me.
I do like all the new views and features the new task manager has though. I spend 99.9% of my time inside the desktop instead of metro. Metro's an awesome application launcher. It's like using quicksilver on OS X
That's for the
You can get volume copies of full editions of 8/2012
The table below lists the qualifying editionns of Windows eligible for the "Volume Licensing upgrade" under each Volume Licensing program.
If your OS license qualifies, "you can purchase the Windows 8 Pro Upgrade license", under your Volume Licensing agreement.
AKA: You can get cheaper upgrade via volume, though I've never messed with upgrade licenses under vol. I suppose that'd be for people without Software Assurance (free exchanges to full copies of the new version in volume license land)
Again: "The following conditions must be met for a licensed PC to be eligible for a Volume Licensing upgrade license:" - VOLUME LICENSEING UPGRADE - not
Suck it up and realize that contract will not fit the model that the win8 store provides and take the loss then. And realize a low power/low cost winrt touch desktop/netbook type thing will mean you're violating the contract anyway.
So let's say that Microsoft promised a market of X users.
Okay, great. Let's assume that for right now, X is 41 million.
Let's assume that of that market, (just for numbers) 1 million is using Surface tablets. So that's a market of 41 million WinRT API/Modern UI/Store devices. Got it. Limit yourself to the ARM devices only: You cut out 40 million possible users. Users like me, who'd actually purchase the game if they could even without a touch screen computer. (I wanted to play this on my laptop....)
Awesome. So you're stuck with 2.4% of the market of clients that could run your product, and you make 52 euros.
What if the same rate of people bought your product if you made it available to 100% of the market?
52 / x = 2.4 / 100
So by the act of clicking a SIMPLE CHECK MARK they could have potentially tapped this market. --- http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-30-15-metablogapi/2112.image111_5F00_551F8980.png --- (yes, it's really that easy)
On windows 8, when you're coding for arm on an x86/x64 machine. your IDE and compiler and simulator are all executing x86/x64 code. You cross compile for testing on ARM device or for distribution. You get x86/x64/arm all at once. There are no code changes to make / porting to do. Limiting it to ARM devices only is a CHOICE of the developer.
Microsoft's design is that I should be able to install the same app on my tablet or my laptop or my desktop if I so choose. The developer blames Microsoft for not having an option that says "you can only download/use the metro app on tablet formfactor devices" and/or a way to enforce this restriction . The developer has a contract that says they can make this game for only tablet formfactor devices(for some awful reason). So to bypass this, they compiled it for ARM only to comply with their supposed restrictions.
They could have increased potential revenue by an insane amount. Instead they locked out 97.6% of the market.
Of course, some apps may be too heavy to execute on ARM so they will not be compiled on that platform, so won't be visible. However, There's no real justifiable reason to not make the application you're targeting for ARM available on x86/x64 as well, except for arbitrary legal ones like this.
What happens if someone makes a low powered touch windows RT pc? the app can now be downloaded onto that and it's not a tablet formfactor device.... and this violates the developer's contract.... But wait! this means the app isn't available on the Surface Pro!
I'm 22 and the BARC hamfest is in 14 days... bought 4 vendor spaces...