I'm in Boucher's district (the fightin' 9th!). He usually runs without significant opposition. Most of the republicans also like him. He'll be re-elected.
Sadly a case of bottled water (don't drink the tap water here, it's often brownish) is around $6. So the 1-2 gallons of water can cost more than filling up my car on some days. This will probably pay for itself in no time for you.
Apple pays ~$254 per device to produce (not including amortized dev costs). That's $145 per device they're still making in profit. They've sold over 1 million of them, so they have their dev costs back.
So unlocked phones only give apple $145, not $145 + $18/month from AT&T.
If you're neutral about Apple and negative about AT&T, you've gotta appreciate apple sticking it to them like this.
If you're against both of them, well, learn more about their competition:-)
All things aside, one way to look at vista's success is the software itself. XP was a desirable set of changes for the end user from ME/98/NT, but Vista?
What was it, really? Sure, it's shipped on (some) new machines, but is there much reason to upgrade for most, the same way XP was?
My point in stripping the executable was that it's a means for software vendors to make reverse engineering harder.
Similarly, vendors tell the os 'Please don't allow gdb or dtrace on me.' Unless I'm alone here, I think the two are pretty similar in concept. Tools like ls and top let you manage the app without learning about its internal structure (the line's a little fuzzy, but I'm not going for a hard stance on this).
Is it really that offensive to prevent gdb and dtrace on an executable? If the internals aren't documented, then the only way to use the tools effectively on the binary is through some degree of reverse engineering, which the vendor doesn't want.
Btw: I'm not too far off: a macbook pro and a sun ultra 40, which is essentially sun's competitor for a mac pro:-)
Re:I didn't go to business school, but...
on
Can Sun Make MySQL Pay?
·
· Score: 4, Informative
The more interesting question is "where aren't the synergies?" Wherever MySQL is deployed, whether the user is paying for software support or not, a server will be purchased, along with a storage device, networking infrastructure - and over time, support services on high value open platforms. Last I checked, we have products in almost all those categories.
In addition, the single biggest impediment to MySQL's growth wasn't the feature set of their technology - which is perfectly married to planetary scale in the on-line/web world. The biggest impediment was that some traditional enterprises wanted a Fortune 500 vendor ("someone in a Gartner magic quadrant") to provide enterprise support. Good news, we can augment MySQL's great service team with an extraordinary set of service professionals across the planet - and provide global mission critical support to the biggest businesses on earth.
So yeah, he's got an idea for the answer, but the author of the TFA knew he didn't have a story if he had read the entire blog entry:-P
I think the idea that people will go "hey, that sun mysql worked out pretty well for us. let's go over to sun.com and see what else they have." isn't a bad one. I think the real kicker will be support. Have some random problem in mysql that's killing you? Pay for an incident with Sun support, and the customer could be well satisfied with what they get back. They like the idea of having a vendor that will actually fix things for you, and suddenly you look at other stuff sun sells that you could get support for.
To put it in perspective, I've got a sun desktop machine (nothing fancy, an amd box that was a lot cheaper than my macbook pro) and it was getting a harmless error message. I put in a support call to sun. Until the issue's fixed (they want me to upgrade the firmware), they've been stalking me to track the ticket. E-mails and voicemail messages ("Did you get a chance to upgrade that firmware yet?") more often than you'd get from a real-life stalker. These kids don't screw around with support. I'm kind of afraid of them for that.
But I'm sure that if you have a problem that's important, you'll appreciate the dedication.
I'm sure there's a lot to be said about companies trusting mysql more now that a big company like sun's behind them, but I'm still in academia, so I donno how much of a factor that is. Probably lots.
Small correction, if you want to distribute proprietary apps, you have to buy a license. If it's something you run yourself, say a website, I don't think you have to distribute the source.
Quick Math: 10 million * 15.00 * 12 = 1.8 billion a year + 10 million * 30 = 300 million a year for the box + expansions (I'm eyeballing this one, but Blizzard did say they wanted an expansion a year)
$2.1 billion. Not bad for a single game! Maybe someone more in-tune with the WoW world can tighten up my estimate of the price of the box + expansions. How much up front? How much for expansions? How frequently?
Frankly, WoW's success shows beyond/. and Kotaku: WoW is nearly a household name now. Congrats to Blizzard for bringing MMOGs to the mainstream.
Fair 'nuff. It's probably enough to keep the higher-ups off the tech's backs about this. Similarly, the old DVD player would block any screen grabber from getting to the DVD image, but you could get at it via Quicktime for Java. A bug surely, but one that you'd see people show off at machack (I think it was an apple dev doing it too, but I forget).
Sure I read the post, I just don't agree with the conclusions.
DTrace works on processes it's supposed to, and doesn't work on those it's not. I'm happy to agree the implementation of the latter is buggy, but I don't think it's the end of the world or a conspiracy theory. Maybe later the providers can be adapted to more intelligently deal with these closed-off processes to give more consistent results.
Apple decided to put in some measures to keep some software locked-down. The correctness of doing so isn't a technical issue, that's a philosophical one.
DTrace is a wonderful tool: one that's saved me *months* off my PhD work, and I love it. And you have my deepest respect for it. But, I don't take dtrace as a philosophy -- I gave up on software religion a long time ago. Everyone's got their own requirements (e.g. locking down iTunes to keep FairPlay from being cracked -- to keep record producers from leaving iTunes) and they've gotta get them done however they can. Call it mercenary ethics if you want, but we don't all work at Sun with CEOs who get it.
As for dtrace working on every process: why? Your claim that 'system level tools' ==> work on any and every process is totally made up. It's not any different from stripping your binaries before shipping them off.
It's a matter of user vs developer rights. Same for developers who want to prevent people from writing key generators for their software: dtrace and gdb would help the hacker, but the developer can give themselves access to it.
If you're one of those freaks who think all software should be free, well, tough. I don't respect your opinion and won't bother responding to you. People have a right to control how their work is used. I don't want any software I write to be used in biological weapons development, and I'd like to keep the right to make sure it doesn't happen. Other people want to feed their families with the software they write. Also fair in my book.
Melodrama aside, it looks like dtrace needs to be fixed to properly deny access. Access is currently denied, as appropriate, but used more CPU than needed to do so. Not exactly broken (which implies a design failure), but a bug.
Hardly a bug worthy of saying "Apple crippled its dtrace port."
Mac haters really are drama queens, aren't they? Here, read this.
Leopard's DTrace isn't broken. Apple put in an API for a program to request that debugging & dtrace be disabled for it. Clearly it's there to keep FairPlay from being broken (too easily). Something that commercial developers could understandably want for their software, to prevent keygen hacks, etc.
The link I provide shows a simple way to get around it. Hell, debugging iTunes is directly encouraged in an Apple Technote (linked in the article).
As listed in the article I linked to, you can get around it by trapping the API call in gdb and disabling it.
Don't let them get hooked on it too early, when they should be able to debug the code by inspection. Cover it later when the problems really need a debugger. Hence the "1st year" qualifier on my statement.
See my response to another person's response on this post (e.g. a response to a sibling in this message tree) for some discussion.
Java's a good first language. It's safer for the student to make common newbie mistakes there, as Java will give you better diagnostics, and makes it harder to screw up royally. Not safer in terms of a nuclear reactor, safer in terms of the student not switching majors. Move on to C++ after that for the lower level stuff. Then cover other languages later. There are multiple courses in a CS program, covering different things. But most of them aren't useful to a student who can't do basic programming yet.
The unrelated digression about GUI libraries I'll assume are a late-night rant, and not a straw man argument. Complain all you want over the use of package names everywhere, but it does make it easier to construct large programs. As all large programs were small once, it makes sense to have them use the language construct early --- it's better than having to rewrite/heavily refactor them later.
As for boilerplate, every language has it. Early students are happy to be told "trust us on this now, we'll explain later when you know more."
1st year students are rarely taught debugging skills
WHY NOT?
Only so many semester-hours in the first year, and plenty of them go to non-CS materials. And frankly, when the kids are still learning to set up a basic for loop, debugging won't help you much. Worse, it'll make kids learn to depend on a debugger for problems that they should learn to figure out themselves. I *shudder* at the thought of students single-stepping simple for loops and method invocations.
Here's my personal history of learning to program.
Yeah, congrats. Think of this: if you had your basic programming skills down pat before switching to lower-level techniques like pointers, linked-list implementations, etc. wouldn't it be an easier learning methodology than jumping in the deep side of the pool early?
Yeah, some self-motivated, self-teaching programmers will go through all of it happily (you and I both did), but this is mainstream education. If we only catered to the innate hackers, we'd have a small fraction of the already-insufficient graduating CS majors we do now. Like 1/10th, easily.
The 2nd year involves building digital circuits and programming raw-metal asm on machines without an OS.
By the 3rd year, those same students who were spoon-fed java are writing kernel code as part of their OS class. I'll happily submit that most self-taught programmers who jumped in the deep end of the pool can't speak to that kind of advancement 2 years after writing their first line of code. The training wheels come off, but they definitely help getting the students up & running.
Furthermore, I know plenty of kids who taught themselves to program at an early age, only to get turned off by it/because/ they got bit too hard by the stuff Java can prevent. I submit that making it easier to learn to program is a better thing than making it harder. Just b/c you make it easier to start with doesn't mean the kids are suddenly weaker for the rest of their life. More often, you end up stunting their long-term growth.
I see where you're coming from (at least I think I do -- you're the ultimate judge on that), but I respectfully disagree.
The advantage to java is that it's safer to make errors there. Screw up with a reference, and you get a nice stacktrace. In C/C++, your program just dies (you can get a debugger on there, sure, but 1st year students are rarely taught debugging skills).
That said, Java's good for getting someone into the proper habits of programming. Let them cut their teeth there - make their typos, basic logic mistakes, etc in a safer sandbox. Teach them how to print out debug statements early to understand what's going on, and to identify what mistakes they often make. When they know how to properly type in a loop construct and declare/invoke a function, then let them play with pointers.
And then you let them use C++. Not the big scary version of C++ everyone in/. is afraid of (IMHO unjustly so), but just the C with classes version. Let them use that for their data structures course. People still have to take a data structures course and write their own implementations of the basic data structures! It's what we do here and it's not too bad an idea -- the kids should get trained on more than one language.
Debuggers are useful here & there, but 90% of the figuring out in a program is complexity spread over way too much code to try and figure out single-stepping in a debugger.
DTrace has taken over for both the debugger & printf() for me. Also, as I can change my script and rerun it on the same running process, my round-trip time has reduced quite a bit.
Swapping an HD in a Pro's about an hour's job. Considering how slowly larger HDDs are available in laptop form factors at decent prices, I'm not complaining that I might have to spend an hour every 2 yrs.
Of course, swapping RAM's still takes less time than to order it from crucial. Goddamn list boxes keep going on forever.
The OO db app supports multiple backends. So a builtin SQLite backend that's easy to work with, and then (already supported) jdbc drivers when you have to go multi-user.
What's the annoyance? I've been hacking some substantial stuff using a mac since the release of 10.0. Terminal, text editors (+ the pretty good mac stuff), compilers and IDEs.
The mac's got the best programmer's text editors out there, bar none. Plus, it's got the linux compatible editors too.
Slashdot Mirror
I'm in Boucher's district (the fightin' 9th!). He usually runs without significant opposition. Most of the republicans also like him. He'll be re-elected.
Apple pays ~$254 per device to produce (not including amortized dev costs). That's $145 per device they're still making in profit. They've sold over 1 million of them, so they have their dev costs back.
:-)
So unlocked phones only give apple $145, not $145 + $18/month from AT&T.
If you're neutral about Apple and negative about AT&T, you've gotta appreciate apple sticking it to them like this.
If you're against both of them, well, learn more about their competition
All things aside, one way to look at vista's success is the software itself. XP was a desirable set of changes for the end user from ME/98/NT, but Vista?
What was it, really? Sure, it's shipped on (some) new machines, but is there much reason to upgrade for most, the same way XP was?
IMHO, no.
My point in stripping the executable was that it's a means for software vendors to make reverse engineering harder.
:-)
Similarly, vendors tell the os 'Please don't allow gdb or dtrace on me.' Unless I'm alone here, I think the two are pretty similar in concept. Tools like ls and top let you manage the app without learning about its internal structure (the line's a little fuzzy, but I'm not going for a hard stance on this).
Is it really that offensive to prevent gdb and dtrace on an executable? If the internals aren't documented, then the only way to use the tools effectively on the binary is through some degree of reverse engineering, which the vendor doesn't want.
Btw: I'm not too far off: a macbook pro and a sun ultra 40, which is essentially sun's competitor for a mac pro
So yeah, he's got an idea for the answer, but the author of the TFA knew he didn't have a story if he had read the entire blog entry
I think the idea that people will go "hey, that sun mysql worked out pretty well for us. let's go over to sun.com and see what else they have." isn't a bad one. I think the real kicker will be support. Have some random problem in mysql that's killing you? Pay for an incident with Sun support, and the customer could be well satisfied with what they get back. They like the idea of having a vendor that will actually fix things for you, and suddenly you look at other stuff sun sells that you could get support for.
To put it in perspective, I've got a sun desktop machine (nothing fancy, an amd box that was a lot cheaper than my macbook pro) and it was getting a harmless error message. I put in a support call to sun. Until the issue's fixed (they want me to upgrade the firmware), they've been stalking me to track the ticket. E-mails and voicemail messages ("Did you get a chance to upgrade that firmware yet?") more often than you'd get from a real-life stalker. These kids don't screw around with support. I'm kind of afraid of them for that.
But I'm sure that if you have a problem that's important, you'll appreciate the dedication.
I'm sure there's a lot to be said about companies trusting mysql more now that a big company like sun's behind them, but I'm still in academia, so I donno how much of a factor that is. Probably lots.
Small correction, if you want to distribute proprietary apps, you have to buy a license. If it's something you run yourself, say a website, I don't think you have to distribute the source.
Quick Math:
/. and Kotaku: WoW is nearly a household name now. Congrats to Blizzard for bringing MMOGs to the mainstream.
10 million * 15.00 * 12 = 1.8 billion a year
+ 10 million * 30 = 300 million a year for the box + expansions (I'm eyeballing this one, but Blizzard did say they wanted an expansion a year)
$2.1 billion. Not bad for a single game! Maybe someone more in-tune with the WoW world can tighten up my estimate of the price of the box + expansions. How much up front? How much for expansions? How frequently?
Frankly, WoW's success shows beyond
Also,I love that Shatner commercial.
Fair 'nuff. It's probably enough to keep the higher-ups off the tech's backs about this. Similarly, the old DVD player would block any screen grabber from getting to the DVD image, but you could get at it via Quicktime for Java. A bug surely, but one that you'd see people show off at machack (I think it was an apple dev doing it too, but I forget).
Sure I read the post, I just don't agree with the conclusions.
DTrace works on processes it's supposed to, and doesn't work on those it's not. I'm happy to agree the implementation of the latter is buggy, but I don't think it's the end of the world or a conspiracy theory. Maybe later the providers can be adapted to more intelligently deal with these closed-off processes to give more consistent results.
Apple decided to put in some measures to keep some software locked-down. The correctness of doing so isn't a technical issue, that's a philosophical one.
DTrace is a wonderful tool: one that's saved me *months* off my PhD work, and I love it. And you have my deepest respect for it. But, I don't take dtrace as a philosophy -- I gave up on software religion a long time ago. Everyone's got their own requirements (e.g. locking down iTunes to keep FairPlay from being cracked -- to keep record producers from leaving iTunes) and they've gotta get them done however they can. Call it mercenary ethics if you want, but we don't all work at Sun with CEOs who get it.
drama queen: read my reply to another post here: http://developers.slashdot.org/comments.pl?sid=426676&cid=22148694
As for dtrace working on every process: why? Your claim that 'system level tools' ==> work on any and every process is totally made up. It's not any different from stripping your binaries before shipping them off.
It's a matter of user vs developer rights. Same for developers who want to prevent people from writing key generators for their software: dtrace and gdb would help the hacker, but the developer can give themselves access to it.
If you're one of those freaks who think all software should be free, well, tough. I don't respect your opinion and won't bother responding to you. People have a right to control how their work is used. I don't want any software I write to be used in biological weapons development, and I'd like to keep the right to make sure it doesn't happen. Other people want to feed their families with the software they write. Also fair in my book.
Melodrama aside, it looks like dtrace needs to be fixed to properly deny access. Access is currently denied, as appropriate, but used more CPU than needed to do so. Not exactly broken (which implies a design failure), but a bug.
Hardly a bug worthy of saying "Apple crippled its dtrace port."
Mac haters really are drama queens, aren't they? Here, read this.
Leopard's DTrace isn't broken. Apple put in an API for a program to request that debugging & dtrace be disabled for it. Clearly it's there to keep FairPlay from being broken (too easily). Something that commercial developers could understandably want for their software, to prevent keygen hacks, etc.
The link I provide shows a simple way to get around it. Hell, debugging iTunes is directly encouraged in an Apple Technote (linked in the article).
As listed in the article I linked to, you can get around it by trapping the API call in gdb and disabling it.
Try an IDE.
Don't let them get hooked on it too early, when they should be able to debug the code by inspection. Cover it later when the problems really need a debugger. Hence the "1st year" qualifier on my statement.
Dude, you missed the point of my post.
See my response to another person's response on this post (e.g. a response to a sibling in this message tree) for some discussion.
Java's a good first language. It's safer for the student to make common newbie mistakes there, as Java will give you better diagnostics, and makes it harder to screw up royally. Not safer in terms of a nuclear reactor, safer in terms of the student not switching majors. Move on to C++ after that for the lower level stuff. Then cover other languages later. There are multiple courses in a CS program, covering different things. But most of them aren't useful to a student who can't do basic programming yet.
The unrelated digression about GUI libraries I'll assume are a late-night rant, and not a straw man argument. Complain all you want over the use of package names everywhere, but it does make it easier to construct large programs. As all large programs were small once, it makes sense to have them use the language construct early --- it's better than having to rewrite/heavily refactor them later.
As for boilerplate, every language has it. Early students are happy to be told "trust us on this now, we'll explain later when you know more."
Only so many semester-hours in the first year, and plenty of them go to non-CS materials. And frankly, when the kids are still learning to set up a basic for loop, debugging won't help you much. Worse, it'll make kids learn to depend on a debugger for problems that they should learn to figure out themselves. I *shudder* at the thought of students single-stepping simple for loops and method invocations.
Yeah, congrats. Think of this: if you had your basic programming skills down pat before switching to lower-level techniques like pointers, linked-list implementations, etc. wouldn't it be an easier learning methodology than jumping in the deep side of the pool early?
Yeah, some self-motivated, self-teaching programmers will go through all of it happily (you and I both did), but this is mainstream education. If we only catered to the innate hackers, we'd have a small fraction of the already-insufficient graduating CS majors we do now. Like 1/10th, easily.
The 2nd year involves building digital circuits and programming raw-metal asm on machines without an OS.
By the 3rd year, those same students who were spoon-fed java are writing kernel code as part of their OS class. I'll happily submit that most self-taught programmers who jumped in the deep end of the pool can't speak to that kind of advancement 2 years after writing their first line of code. The training wheels come off, but they definitely help getting the students up & running.
Furthermore, I know plenty of kids who taught themselves to program at an early age, only to get turned off by it
I see where you're coming from (at least I think I do -- you're the ultimate judge on that), but I respectfully disagree.
/. is afraid of (IMHO unjustly so), but just the C with classes version. Let them use that for their data structures course. People still have to take a data structures course and write their own implementations of the basic data structures! It's what we do here and it's not too bad an idea -- the kids should get trained on more than one language.
The advantage to java is that it's safer to make errors there. Screw up with a reference, and you get a nice stacktrace. In C/C++, your program just dies (you can get a debugger on there, sure, but 1st year students are rarely taught debugging skills).
That said, Java's good for getting someone into the proper habits of programming. Let them cut their teeth there - make their typos, basic logic mistakes, etc in a safer sandbox. Teach them how to print out debug statements early to understand what's going on, and to identify what mistakes they often make. When they know how to properly type in a loop construct and declare/invoke a function, then let them play with pointers.
And then you let them use C++. Not the big scary version of C++ everyone in
multiple antennas will get you a position.
Put solaris 10 on a PC (or vmware or what not). Then, start tracing function (& method) call invocations. Use ustack() to save the stack at the point of invocation. :-)
For C++: http://developers.sun.com/solaris/articles/dtrace_cc.html
Java: http://www.devx.com/Java/Article/33943
C: The dtrace docs
Debuggers are useful here & there, but 90% of the figuring out in a program is complexity spread over way too much code to try and figure out single-stepping in a debugger.
DTrace has taken over for both the debugger & printf() for me. Also, as I can change my script and rerun it on the same running process, my round-trip time has reduced quite a bit.
Swapping an HD in a Pro's about an hour's job. Considering how slowly larger HDDs are available in laptop form factors at decent prices, I'm not complaining that I might have to spend an hour every 2 yrs.
Of course, swapping RAM's still takes less time than to order it from crucial. Goddamn list boxes keep going on forever.
The OO db app supports multiple backends. So a builtin SQLite backend that's easy to work with, and then (already supported) jdbc drivers when you have to go multi-user.
The screenshots seem to show that all it detects are evidence of viewing porn sites. Yes, you can view smut on the mac. Everyone go hide in fear.
What's the annoyance? I've been hacking some substantial stuff using a mac since the release of 10.0. Terminal, text editors (+ the pretty good mac stuff), compilers and IDEs.
The mac's got the best programmer's text editors out there, bar none. Plus, it's got the linux compatible editors too.
The battery on iPhones & iPods isn't removable to make the device thinner.