No, you can just use set a boolean in your inner-loop that outer-loops use when you break from the inner-loop. Also, you can create inline functions if you really wanted to go that route.
As for C++, 64 KB of bloat for exceptions is nothing compared to the performance cost of handling exceptions. For the architectures you mentioned, it's an issue, which is why C++ either isn't used or is used without exceptions. However, for the majority of systems, exception-handling performance trumps a boost in run-time size.
He doesn't mean he necessarily thinks it doesn't exist. I think he is willing to accept that negative mass could exist, but not because someone says it must exist for FTL to be solved.
Of course, for me the "year of the Linux desktop" was years ago. And because of this, I'd like to see it more widespread. Mainly because you are right - there are some proprietary software that has no equivalent. I'd really like the option of buying said software and running it on my platform of choice. But that's not really anything more than a personal wish.
How much time did you spend getting your desktop running? I've run them as well (and still do), and it took a lot more time to get it running than it did the first time I ever used Windows or OS X. I haven't ever heard anyone say that they had a first-time full multimedia setup going in a FOSS OS faster than their first-time full multimedia setup in Windows or OS X. Newbs just don't know about Xine, VLC, all the codecs they'll need, where to get them, or how to handle their package management systems until they spend plenty of time reading about them. And, really, time is money, and it may cost too much in certain situations.
Yeah. We're never going to see a Tivo, TomTom, or Google. We're never going to see the various private architectures I've supported for my employers. Just not going to happen.
I think perhaps I wasn't clear with what I meant. I meant that people aren't going to create an innovative solution as a FOSS platform, because there is no immediate reward. Because, like I said, people want and need money. As far as I know, none of the products you mentioned are open-source; by the time they are (if ever), it will be because they see no more benefit in keeping them proprietary.
I also use a lot of FOSS and a mix of proprietary. I always give the FOSS solutions additional points in any given consideration. I hate being beholden to any given vendor for numerous reasons. FOSS gives me options that proprietary solutions rarely (if ever) provide. But there are times that a proprietary solution is just too good to pass up. We will then risk it and deal with the risk involved (sometimes we never have to worry about it, sometimes we get bitten).
So, you give FOSS a higher default rating based on an ideological reason rather than an objective one? It sounds like you let personal views cloud your judgement when making software decisions. FOSS should only be one factor in the acquisition of something for use. I also think that in terms of TCO, going with an excellent proprietary solution, even if it is converted to a better FOSS alternative in the future, will be lower with the proper development team in place. The only time this may not be the case is if you have a team of developers that's really going to broaden the base product and make it genuinely awesome for your task.
Really, the software we use should be used because it's the best tool for the job. If it's a FOSS solution, great. If you have to pay for the appropriate tool, do it. Vary your choices according to objective reasoning and budget constraints. If you feel a FOSS alternative should be created, do it, but that points back to my point about people not innovating on FOSS platforms.
I think you're mistaken about proprietary software being on the way out. We haven't had a "Year-of-the-Linux-desktop" yet, and some proprietary software is just plain better than FOSS alternatives, if a FOSS alternative even exists.
I don't think most companies are ever going to innovate on a FOSS platform, because there isn't any real money there. Innovation is driven by money, and people want it. FOSS, thus far, has typtically shown itself to be promising when commoditizing solutions.
Not to say that I don't love FOSS applications. I have a FreeBSD NAS/router I built at home, and I use lots of FOSS components on my systems. However, some of the coolest new apps I see are proprietary, at least until a good FOSS alternative is released, in which case it's no longer new.
At work we also use lots of FOSS, but we also use lots of proprietary tech. I think the real value comes by using both to get the best of both worlds, and I think most people in the world that care about staying on top think this way as well.
I think you just needed more discrete mathematics and more combinatorics and graph theory. Then the compiler course would've made a lot more sense up front when learning about recursive-descent parsers vs. LL(k) parsers vs. LR/LALR parsers and where the strength of each one lies, how it's making your life easier/harder, etc.
I did that middleware OS stuff you mentioned though, and I have to agree that it was sometimes pretty useless. Working directly with, say, a Linux, FreeBSD, or Minix kernel+OS would've gone a lot further and made you feel like you were accomplishing something that could immediately be put to use.
I agree with the idea of pushing/encouraging your students to learn research on their own and to learn how to WANT to research. Bjarne was also advocating that in the summary (I didn't read TFA), and I think it's the most important step to teaching.
Actually, you should look up "dependent". You say we it's okay to use it, but we shouldn't be dependent on it. Well, then why use it at all? Dependent just means we require its use, and if we want more accuracy, we do require its use. I'm preeeeeeettty sure we will still know how to use and will still have radar in case there are problems.
You know, that same government you mention could very well do the same thing with our existing radar network. So, what's the difference? Also, with satellites, we can still do visual recognition if we think something is amiss. So, technically, we're getting even MORE failsafes.
Take off your tinfoil hat now.
Except, as you may recall from the recent US Supreme Court case regarding the Exxon Valdez, punitive damages may be no larger than the actual damages incurred. So, if Psystar sold 1,000 systems that would've normally cost $2,000 each from Apple for a similar system, Psystar would be (maybe) liable for $2,000,000 in punitive damages. Proving that these people would've bought Apple computer in the first place after choosing a cheaper alternative would be hard though. So, I would expect punitive damages to be less.
Heh, you got screwed man. Make the landlord pay any fee, and if a fee is going to be paid, why the hell would you pay 15%? The going rate is 5-6%. Wow.... just, wow.
Slashdot Mirror
No, you can just use set a boolean in your inner-loop that outer-loops use when you break from the inner-loop. Also, you can create inline functions if you really wanted to go that route.
As for C++, 64 KB of bloat for exceptions is nothing compared to the performance cost of handling exceptions. For the architectures you mentioned, it's an issue, which is why C++ either isn't used or is used without exceptions. However, for the majority of systems, exception-handling performance trumps a boost in run-time size.
He doesn't mean he necessarily thinks it doesn't exist. I think he is willing to accept that negative mass could exist, but not because someone says it must exist for FTL to be solved.
Of course, for me the "year of the Linux desktop" was years ago. And because of this, I'd like to see it more widespread. Mainly because you are right - there are some proprietary software that has no equivalent. I'd really like the option of buying said software and running it on my platform of choice. But that's not really anything more than a personal wish.
How much time did you spend getting your desktop running? I've run them as well (and still do), and it took a lot more time to get it running than it did the first time I ever used Windows or OS X. I haven't ever heard anyone say that they had a first-time full multimedia setup going in a FOSS OS faster than their first-time full multimedia setup in Windows or OS X. Newbs just don't know about Xine, VLC, all the codecs they'll need, where to get them, or how to handle their package management systems until they spend plenty of time reading about them. And, really, time is money, and it may cost too much in certain situations.
Yeah. We're never going to see a Tivo, TomTom, or Google. We're never going to see the various private architectures I've supported for my employers. Just not going to happen.
I think perhaps I wasn't clear with what I meant. I meant that people aren't going to create an innovative solution as a FOSS platform, because there is no immediate reward. Because, like I said, people want and need money. As far as I know, none of the products you mentioned are open-source; by the time they are (if ever), it will be because they see no more benefit in keeping them proprietary.
I also use a lot of FOSS and a mix of proprietary. I always give the FOSS solutions additional points in any given consideration. I hate being beholden to any given vendor for numerous reasons. FOSS gives me options that proprietary solutions rarely (if ever) provide. But there are times that a proprietary solution is just too good to pass up. We will then risk it and deal with the risk involved (sometimes we never have to worry about it, sometimes we get bitten).
So, you give FOSS a higher default rating based on an ideological reason rather than an objective one? It sounds like you let personal views cloud your judgement when making software decisions. FOSS should only be one factor in the acquisition of something for use. I also think that in terms of TCO, going with an excellent proprietary solution, even if it is converted to a better FOSS alternative in the future, will be lower with the proper development team in place. The only time this may not be the case is if you have a team of developers that's really going to broaden the base product and make it genuinely awesome for your task.
Really, the software we use should be used because it's the best tool for the job. If it's a FOSS solution, great. If you have to pay for the appropriate tool, do it. Vary your choices according to objective reasoning and budget constraints. If you feel a FOSS alternative should be created, do it, but that points back to my point about people not innovating on FOSS platforms.
I think you're mistaken about proprietary software being on the way out. We haven't had a "Year-of-the-Linux-desktop" yet, and some proprietary software is just plain better than FOSS alternatives, if a FOSS alternative even exists.
I don't think most companies are ever going to innovate on a FOSS platform, because there isn't any real money there. Innovation is driven by money, and people want it. FOSS, thus far, has typtically shown itself to be promising when commoditizing solutions.
Not to say that I don't love FOSS applications. I have a FreeBSD NAS/router I built at home, and I use lots of FOSS components on my systems. However, some of the coolest new apps I see are proprietary, at least until a good FOSS alternative is released, in which case it's no longer new.
At work we also use lots of FOSS, but we also use lots of proprietary tech. I think the real value comes by using both to get the best of both worlds, and I think most people in the world that care about staying on top think this way as well.
Did anyone else read that as: "SpaceX Successfully Tested Disco Thruster"?
No.
I think you just needed more discrete mathematics and more combinatorics and graph theory. Then the compiler course would've made a lot more sense up front when learning about recursive-descent parsers vs. LL(k) parsers vs. LR/LALR parsers and where the strength of each one lies, how it's making your life easier/harder, etc. I did that middleware OS stuff you mentioned though, and I have to agree that it was sometimes pretty useless. Working directly with, say, a Linux, FreeBSD, or Minix kernel+OS would've gone a lot further and made you feel like you were accomplishing something that could immediately be put to use. I agree with the idea of pushing/encouraging your students to learn research on their own and to learn how to WANT to research. Bjarne was also advocating that in the summary (I didn't read TFA), and I think it's the most important step to teaching.
Actually, you should look up "dependent". You say we it's okay to use it, but we shouldn't be dependent on it. Well, then why use it at all? Dependent just means we require its use, and if we want more accuracy, we do require its use. I'm preeeeeeettty sure we will still know how to use and will still have radar in case there are problems. You know, that same government you mention could very well do the same thing with our existing radar network. So, what's the difference? Also, with satellites, we can still do visual recognition if we think something is amiss. So, technically, we're getting even MORE failsafes. Take off your tinfoil hat now.
Except, as you may recall from the recent US Supreme Court case regarding the Exxon Valdez, punitive damages may be no larger than the actual damages incurred. So, if Psystar sold 1,000 systems that would've normally cost $2,000 each from Apple for a similar system, Psystar would be (maybe) liable for $2,000,000 in punitive damages. Proving that these people would've bought Apple computer in the first place after choosing a cheaper alternative would be hard though. So, I would expect punitive damages to be less.
Heh, you got screwed man. Make the landlord pay any fee, and if a fee is going to be paid, why the hell would you pay 15%? The going rate is 5-6%. Wow.... just, wow.