I've seen some people in weird clothing, with piercings and blue hair and stuff. For as long as you do a good job, no one cares or even notices.
There still is some rudimentary dress code, though. You can't come to work wearing nothing but underwear for example. There's a legend, and I don't know if it's true or not, that once upon a time there was a guy at MSFT who was too cheap to rent an appartment. So he lived in his office. One Sunday someone caught him in his underwear watching TV in a conference room. The guy got fired. So there you go. Start the party, bash Microsoft for its oppression of nudity in the workplace.:0)
Managing developers is a job for development manager and leads reporting to him. Architect should be, ahem, coming up with an architecture. If someone catches an architect writing software to manage people the guy should be fired on the spot because he's wasting money.
Second thing is, you're headed down the wrong track. No one can effectively manage 125 items at the same time, not even with good software. That's why most if not all development teams divide the entire product cycle into several milestones (3 to 5 usually) with clearly defined work items and deliverables in each. You don't exit the milestone until shit gets done and reaches acceptable level of quality. If schedule doesn't work, you make feature cuts. If you can't cut something, you adjust the schedule.
By dividing 125 items into five buckets you only get 25 items in each bucket. A perfectly manageable number if you delegate some of the management to development leads. Heck, you can even hold 25 items in your head without any software at all.
What you're talking about is a slippery bureocratic slope which leads nowhere. You're trying to replace proper planning and management with "a shell script" and that just doesn't work for a thousand of reasons.
What happens with components that are not "bad" but are "on the verge" and can go bad any minute? Something tells me that there will be a lot more of those in a chip where "bad" components are perfectly fine. They're impossible to detect, too, because during QA they'll work perfectly fine.
I see this tech as a temporary crutch for something more advanced - self diagnosing and self-healing chips. Now that would be frikkin' cool.
Create the fucking "Photoshop Killer" already. Adobe customers need it to get some competition to bring the prices down if nothing else. Right now if you're a digital photographer and you want a high bit depth color managed workflow you have no choice but to use Photoshop. That's fucked up.
NOTHING will be in Longhorn by default. They threw everything away from the main branch and now to re-enter the branch individual teams must pass a hardcore quality bar. It's unlike anything you've seen before. The code must build on all platforms and must pass all unit tests. It must also pass static code analysis. These are not the only requirements there. With every major release Microsoft reinvents their development model for Windows (because the team size doubles). This was a painful but necessary evolution. I have no doubt this will have measurable benefits, in terms of security, stability and overall architectural consistency.
So FOSS community should be writing code like mad right now instead of this verbal masturbation as to what will and will not make it into longhorn. There are very few pieces without which longhorn will not ship. Other things will depend on the efforts of the individual teams, and folks are willing to go the extra mile, so chances are some of the things that you've heard won't make it into longron will end up shipping.
After six years of blasting Microsoft (sometimes deservedly), FOSS community will be caught with their pants down. And BillG will not skimp on lubricants, you know.
1. From Objective-C to something faster and less brain damaged. Let's face it, there's NO tangible benefit to using Objective-C. None. It's just an additional cost and pain in the ass.
2. From microkernel to something less taxing in IPC department. Otherwise app startup times and multithreaded app performance will remain as crappy as they are now.
3. From 32 bit to 64 bit for UI apps. Right now only console apps can be 64 bit.
In three years, no more, current Power PC users will be SOL. And not only on Mac OS X, I expect Linux developers to migrate away from the platform that's now officially dead.
iMac G5, 1GB ram, 1.8GHz processor, 7200RPM hard drive is about 30% slower than my Pentium-M laptop with1 1.5GHz processor, 1GB RAM and 5400RPM hard drive. Operations that I've compared:
1. Opening a large TIFF file (130M 48bit film scan) 2. Conversion to LAB color mode 3. Saving a large TIFF file 4. Converting to a different color profile 5. Unsharp mask
ALL are slower on the Mac. Why? Perhaps because Adobe Mac sales are only 20% of their overall Photoshop sales?
We'll see who was right 6 to 8 months from now.:0)
There IS a need to convert UI to 64 bit if you want UI apps to support 64 bit. Your apps can't go across 32/64 bit boundaries seamlessly. Currently only console apps support 64 bit addressing and code.
To them Intel or IBM don't make any difference. In fact, I'd bet good money that at least 80% of their customers (current and prospective) don't know about the switch and what it means.
I predict the following: 1. As sales slow down (and they WILL slow down to zero over the next year or so), Apple will heavily drop the price on G5 and G4 based models, including laptops. This won't help the sales much, but people wanting to sell their Macs will only be able to sell them for a lot less.
2. This is not the last "switch" Apple has in the pipeline. The next one will be the switch from slow and brain damaged Objective-C as the language of choice for Mac OS X programming. This one will be painful to everyone but people who kept using Carbon (that's actually a lot of people).
3. Once Intel platforms start hitting the market Apple users will be shocked by just how much _slower_ Mac OS X is on the same processor compared to Windows (or Linux if it makes inroads). That's microkernel and IPC, there's no way around this cost short of throwing microkernel architecture out of the window. Another switch?
4. Yet another switch is coming. Apple UI is currently 32 bit, so you can only run your console apps in 64 bit mode. 64 bit editions of Win XP are not castrated in this regard, and I have no reason to think that Longhorn will be. So Apple will have to convert Cocoa to 64 bit.
Each of the last three "switches" is a cost to the developer. At some point developers will just say "fuck it" and go develop software for Longhorn.
The main problem will be the cost of producing software for multiple platforms. It's not as easy as Steve wants you to believe. Plus, when you add another platform your QA cost DOUBLES. It's not like Mac-only development businesses are bathing in money right now.
The next thing that will happen is folks who have been using AltiVec heavily (maybe even Apple themselves) will rip it out and replace it with plain ol' C code that they can simply recompile for Intel. When Apple rolls out Intel machines, these same folks will start optimizing for SSE/SSE2/SSE3/MMX and Power PC versions will only have slow C versions of the same functions. Therefore P4 versions will fly, and Power PC versions will crawl.
Then, perhaps in 2008, you will see binaries targeting solely Intel machines. And you'll be SOL with your good looking G5 dualie. You won't be able to sell it for much either, who needs a machine that can't run contemporary software AT ALL.
Many Mac buyers consider their purchases as investments. They buy a machine, work on it for a couple of years, then put it on ebay and buy something else. This is precisely the category of Mac userbase that's getting the shaft this time around.
I've dumped everything Apple the day after the switch announcement. It's my money, and I'd rather not serve as a guinea pig for Steve Jobs & co. I liked the hardware and the software, but it's not THAT much better than either Linux or Windows. In fact, in some cases it's less polished than on Windows. Photoshop runs MUCH faster on Windows, too.
So I'll be running Windows and Linux until SJ makes up his fucking mind. This lesson cost me around $600. Fool me once, shame on you so to speak. Won't get fooled again.
They will still have to spend a lot of effort porting patches from there. Think about it, if Apple gave a shit about cross-platform coding, KHTML team would just recompile stuff on Linux and it would just work, perhaps with a few minor tweaks. If they crap Cocoa and Carbon code all over the place, you first need to remove that and THEN port what's left. Having worked with large codebases I can say this is only worth the effort in rare cases, and most of the time it's easier to see what was changed and re-implement something similar, not backport.
I can't blame Apple for any of this, though, especially after they've opened up CVS.
Funny that, I can already buy dual-core chips at Newegg. As a side note, dual core P4's are about one half to one third as expensive as dual core Opterons. In fact, dual core P4's start at a mere $311, whereas opterons start at $900+. Looks like AMD has some re-pricing to do.
You'd think they'd employ their own courier to move backups with sensitive data. This just shows how much value they put in their customers' security, financial and otherwise. If I were their customer, I'd be closing my accounts with them NOW.
This means NO MORE NEW SOFTWARE for you. No Mac OS X, no iLife, no Final Cut Express, no Photoshop. You will _maybe_ get another version or so and after that you're S.O.L.
This sucks so hard, it's unbelievable. Expect a flood of cheap Macs on ebay in the coming weeks.
1. Low-end desktops suck so bad, I wouldn't buy one if someone points a gun to my head. Just go to Circuit City or Best Buy and look at them. Do you want to buy this crap?
2. I'm writing this lying on the couch. There's no going back to desktop once you go completely wireless. The only desktop I have is iMac G5, but that's only because I need a good display for digital photography, and iMac display is top-notch. If Apple puts decent panels into the next crop of their laptops, this iMac may go to ebay.
Slashdot Mirror
Multi-tier enterprise development in Javascript
Writing readable code in Brainfuck
Windows 98 Server Administration and Security
He's an old fart, and he still looks like he's barely 40!
Heh, this may breathe some life into the internal "Linux Users" Exchange discussion group.
These tin cans have been flown two dozen times each. I think they can blow up pretty much on any reentry.
Your Nissan won't blow up on reentry to garage. Or when you drive on your driveway in the morning.
I've seen some people in weird clothing, with piercings and blue hair and stuff. For as long as you do a good job, no one cares or even notices.
:0)
There still is some rudimentary dress code, though. You can't come to work wearing nothing but underwear for example. There's a legend, and I don't know if it's true or not, that once upon a time there was a guy at MSFT who was too cheap to rent an appartment. So he lived in his office. One Sunday someone caught him in his underwear watching TV in a conference room. The guy got fired. So there you go. Start the party, bash Microsoft for its oppression of nudity in the workplace.
Managing developers is a job for development manager and leads reporting to him. Architect should be, ahem, coming up with an architecture. If someone catches an architect writing software to manage people the guy should be fired on the spot because he's wasting money.
Second thing is, you're headed down the wrong track. No one can effectively manage 125 items at the same time, not even with good software. That's why most if not all development teams divide the entire product cycle into several milestones (3 to 5 usually) with clearly defined work items and deliverables in each. You don't exit the milestone until shit gets done and reaches acceptable level of quality. If schedule doesn't work, you make feature cuts. If you can't cut something, you adjust the schedule.
By dividing 125 items into five buckets you only get 25 items in each bucket. A perfectly manageable number if you delegate some of the management to development leads. Heck, you can even hold 25 items in your head without any software at all.
What you're talking about is a slippery bureocratic slope which leads nowhere. You're trying to replace proper planning and management with "a shell script" and that just doesn't work for a thousand of reasons.
What happens with components that are not "bad" but are "on the verge" and can go bad any minute? Something tells me that there will be a lot more of those in a chip where "bad" components are perfectly fine. They're impossible to detect, too, because during QA they'll work perfectly fine.
I see this tech as a temporary crutch for something more advanced - self diagnosing and self-healing chips. Now that would be frikkin' cool.
Create the fucking "Photoshop Killer" already. Adobe customers need it to get some competition to bring the prices down if nothing else. Right now if you're a digital photographer and you want a high bit depth color managed workflow you have no choice but to use Photoshop. That's fucked up.
NOTHING will be in Longhorn by default. They threw everything away from the main branch and now to re-enter the branch individual teams must pass a hardcore quality bar. It's unlike anything you've seen before. The code must build on all platforms and must pass all unit tests. It must also pass static code analysis. These are not the only requirements there. With every major release Microsoft reinvents their development model for Windows (because the team size doubles). This was a painful but necessary evolution. I have no doubt this will have measurable benefits, in terms of security, stability and overall architectural consistency.
So FOSS community should be writing code like mad right now instead of this verbal masturbation as to what will and will not make it into longhorn. There are very few pieces without which longhorn will not ship. Other things will depend on the efforts of the individual teams, and folks are willing to go the extra mile, so chances are some of the things that you've heard won't make it into longron will end up shipping.
After six years of blasting Microsoft (sometimes deservedly), FOSS community will be caught with their pants down. And BillG will not skimp on lubricants, you know.
There are a few more in the pipeline:
1. From Objective-C to something faster and less brain damaged. Let's face it, there's NO tangible benefit to using Objective-C. None. It's just an additional cost and pain in the ass.
2. From microkernel to something less taxing in IPC department. Otherwise app startup times and multithreaded app performance will remain as crappy as they are now.
3. From 32 bit to 64 bit for UI apps. Right now only console apps can be 64 bit.
And you're gonna pay every step of the way.
In three years, no more, current Power PC users will be SOL. And not only on Mac OS X, I expect Linux developers to migrate away from the platform that's now officially dead.
iMac G5, 1GB ram, 1.8GHz processor, 7200RPM hard drive is about 30% slower than my Pentium-M laptop with1 1.5GHz processor, 1GB RAM and 5400RPM hard drive. Operations that I've compared:
1. Opening a large TIFF file (130M 48bit film scan)
2. Conversion to LAB color mode
3. Saving a large TIFF file
4. Converting to a different color profile
5. Unsharp mask
ALL are slower on the Mac. Why? Perhaps because Adobe Mac sales are only 20% of their overall Photoshop sales?
We'll see who was right 6 to 8 months from now. :0)
There IS a need to convert UI to 64 bit if you want UI apps to support 64 bit. Your apps can't go across 32/64 bit boundaries seamlessly. Currently only console apps support 64 bit addressing and code.
To them Intel or IBM don't make any difference. In fact, I'd bet good money that at least 80% of their customers (current and prospective) don't know about the switch and what it means.
I predict the following:
1. As sales slow down (and they WILL slow down to zero over the next year or so), Apple will heavily drop the price on G5 and G4 based models, including laptops. This won't help the sales much, but people wanting to sell their Macs will only be able to sell them for a lot less.
2. This is not the last "switch" Apple has in the pipeline. The next one will be the switch from slow and brain damaged Objective-C as the language of choice for Mac OS X programming. This one will be painful to everyone but people who kept using Carbon (that's actually a lot of people).
3. Once Intel platforms start hitting the market Apple users will be shocked by just how much _slower_ Mac OS X is on the same processor compared to Windows (or Linux if it makes inroads). That's microkernel and IPC, there's no way around this cost short of throwing microkernel architecture out of the window. Another switch?
4. Yet another switch is coming. Apple UI is currently 32 bit, so you can only run your console apps in 64 bit mode. 64 bit editions of Win XP are not castrated in this regard, and I have no reason to think that Longhorn will be. So Apple will have to convert Cocoa to 64 bit.
Each of the last three "switches" is a cost to the developer. At some point developers will just say "fuck it" and go develop software for Longhorn.
The main problem will be the cost of producing software for multiple platforms. It's not as easy as Steve wants you to believe. Plus, when you add another platform your QA cost DOUBLES. It's not like Mac-only development businesses are bathing in money right now.
The next thing that will happen is folks who have been using AltiVec heavily (maybe even Apple themselves) will rip it out and replace it with plain ol' C code that they can simply recompile for Intel. When Apple rolls out Intel machines, these same folks will start optimizing for SSE/SSE2/SSE3/MMX and Power PC versions will only have slow C versions of the same functions. Therefore P4 versions will fly, and Power PC versions will crawl.
Then, perhaps in 2008, you will see binaries targeting solely Intel machines. And you'll be SOL with your good looking G5 dualie. You won't be able to sell it for much either, who needs a machine that can't run contemporary software AT ALL.
Many Mac buyers consider their purchases as investments. They buy a machine, work on it for a couple of years, then put it on ebay and buy something else. This is precisely the category of Mac userbase that's getting the shaft this time around.
I've dumped everything Apple the day after the switch announcement. It's my money, and I'd rather not serve as a guinea pig for Steve Jobs & co. I liked the hardware and the software, but it's not THAT much better than either Linux or Windows. In fact, in some cases it's less polished than on Windows. Photoshop runs MUCH faster on Windows, too.
So I'll be running Windows and Linux until SJ makes up his fucking mind. This lesson cost me around $600. Fool me once, shame on you so to speak. Won't get fooled again.
You forgot CEO, CFO, CTO and CIO. These folks alone can suck in $100M in a single year (outsourcing the project itself to India).
It kinda didn't work out. In fact what you said is what Apple ended up doing, thus the problems with backporting fixes.
They will still have to spend a lot of effort porting patches from there. Think about it, if Apple gave a shit about cross-platform coding, KHTML team would just recompile stuff on Linux and it would just work, perhaps with a few minor tweaks. If they crap Cocoa and Carbon code all over the place, you first need to remove that and THEN port what's left. Having worked with large codebases I can say this is only worth the effort in rare cases, and most of the time it's easier to see what was changed and re-implement something similar, not backport.
I can't blame Apple for any of this, though, especially after they've opened up CVS.
Funny that, I can already buy dual-core chips at Newegg. As a side note, dual core P4's are about one half to one third as expensive as dual core Opterons. In fact, dual core P4's start at a mere $311, whereas opterons start at $900+. Looks like AMD has some re-pricing to do.
You'd think they'd employ their own courier to move backups with sensitive data. This just shows how much value they put in their customers' security, financial and otherwise. If I were their customer, I'd be closing my accounts with them NOW.
This means NO MORE NEW SOFTWARE for you. No Mac OS X, no iLife, no Final Cut Express, no Photoshop. You will _maybe_ get another version or so and after that you're S.O.L.
This sucks so hard, it's unbelievable. Expect a flood of cheap Macs on ebay in the coming weeks.
Where can I buy a 20" powerbook? :0)
Seriously, though. It's not the same, and the difference is pretty dramatic. Panels in Apple desktops are MUCH better.
1. Low-end desktops suck so bad, I wouldn't buy one if someone points a gun to my head. Just go to Circuit City or Best Buy and look at them. Do you want to buy this crap?
2. I'm writing this lying on the couch. There's no going back to desktop once you go completely wireless. The only desktop I have is iMac G5, but that's only because I need a good display for digital photography, and iMac display is top-notch. If Apple puts decent panels into the next crop of their laptops, this iMac may go to ebay.