Re:Mastering video DVDs under linux IS easy
on
NeroLinux vs. K3b
·
· Score: 1
I can only say that it's going to be interesting when the Windows version of QT4 is available under the GPL and so most of KDE4 can (and will) be ported to Windows.
There are quite a few noteworthy KDE apps that punch well above their weight in comparison to Windows-only closed-source alternatives. K3B is one, apparently (I haven't used it), but I could see Konqueror (especially if people get the idea it's like Safari-for-Windows), KDevelop, Quanta and perhaps even KOffice and KMail getting a bit of attention.
If the company behind Nero is aware that K3B will be making an appearance on Windows eventually, they should be at least a bit concerned - especially if an ordinary user can come to the same conclusion as this reviewer ("Hmmm, nicer interface, much more usable, works fine, free...").
Of course, it'll mostly depend on whether your average Windows-only person ever becomes aware of the wide range of KDE4 software that they'll be able to install on their Windows machine. I suspect the KDE people wouldn't be that interested in an organised marketing effort at Windows users...
but stranger things have happened. Anyway, word-of-mouth can be disturbingly effective.:)
You've missed the point. If a company sends you commercial propaganda email that you didn't specifically request - and you didn't give them permission to send (to you) - then they're spamming you.
You shouldn't ever ask a spammer to "remove" you from their list.... even if they did remove you (and some do) who would want to be in debt to a spammer? Alternatively, if enough people report them, they'll (sooner or later) get added to mainstream RBLs - then they can just sit there and wail "No no, you've got us all wrong, spamming is what other people do!":-)
I'm presuming this is some sort of weird troll, moderated "informative" for some odd reason (seriously moderator, "informative"? What derf?)
Seriously, if you think the Microsoft development tools are far superior to
anythingelseintheworld,
then I can only presume you've never used anything else in the world:).
Ha. That's funny. WEBoggle was probably the major inspiration for the stuff I'm working on, when I first discovered it a few months ago. It's really a brilliant implementation of Boggle - so simple and enjoyable. Great fun.
Even though my partner is now dreadfully addicted to it:), I must thank you for making it. It's really cool.
When I have a bit more time I'm thinking of having a bash at implementing a
Fungus
clone using this sort of technology - there's probably a huge variety of simple-but-addictive games that'd be well suited to this kind of framework.
I'm working on a project at the moment that's all Javascript on the client side and mod_python (with the very nice Publisher handler on the server. I have a simple Javascript wrapper around XMLHttpRequest for making asynchronous calls to the server (using CPS
with Javascript closures as the "continuations") and I just pass all the info back in JSON format, so I can just eval() the returned text.
Surprisingly neat and (very) surprisingly flexible - you can also do stuff like pass back Javascript functions (from the server) along with the data you wish to process.
You can use the Python str() function for the most simple data conversions (eg. an array or a dictionary), but I prefer the pyjsonrpc
package which has very nice little objToJson and jsonToObj functions. Better than just using Python's str() function, as it also strips out excess whitespace. I also modified it slightly to also properly convert Python booleans to Javascript booleans (it already handled null to None conversions).
It all works very nicely, a testament to the power of simplicity. The Javascript (client) side just makes requests in response to user actions (eg. button clicks) or other events, and the server responds to those requests with Javascript data (CPS is very well suited to this kind of programming).
Javascript really is a
verycool
programming language. I've implemented my own
python.js library which adds a handful of Python-like functional programming facilities to Javascript (eg. map, filter, reduce) and dictionary/object methods like keys() and values(). It's got to the point now where I sometimes get confused as to whether I'm writing Javascript or Python, because they're so similar
in all the ways that really matter.
This kind of web development is quite fun. I also have a nice advantage with the web application I'm working on, as it flat-out can't run on IE (it uses fixed-positioned divs quite extensively, along with a few other standard features that IE can't handle) and so I don't have to worry about compatibility with that fucking mess of a browser. Hooray.:-)
The only reason you bother to press the "Submit" button on Slashdot is because you want someone else to read your words, true?
In that case, when you write you should care more about the people reading than yourself as the person writing. There are lots of conventions when writing English text - and while some are strange, there's a good reason for most of them. The reason for using capital letters at the start of sentences is fairly obvious - it helps to visually distinguish the start of a sentence.
Breaking the text into conceptual blocks (ie. paragraphs) is another thing that helps the reader and doesn't (necessarily) do anything for the writer (certainly if you're the kind of writer that doesn't bother to read your own words).
If you don't want to expend the trivial extra effort to follow basic conventions for written text, nobody's going to drag you up before the Literacy Police. Nobody's going to care. Because nobody's going to bother reading what you write.
Wow. I agree with Jericho4.0. Kids. And fairly stupid kids at that, several steps below your average script kiddie.
For some reason I'm very strongly reminded of this line:-).
Some of the bits from the article were pretty revealing too - one of the group members who was failing a CS degree because he never went to lectures and never studied (too busy "ripping and burning"). I'm guessing he didn't do the exams either:).
And of course, who could forget that very scary and extremely serious and realistic </sarcasm> threat to the author of the article: "You do not need some 350-pound hit man with a Glock at your front door." Someone's been living a bit too much in movie fantasy-land, methinks.
Put it this way - you're just not going to be getting that many legitimate orders for high-end laptops from, say, Indonesia... at least compared to the blizzard of orders using stolen credit card numbers. It's much simpler and more cost-effective for the merchant to say "Nope, we just won't accept orders from $COUNTRIES."
Of course, feel free to substitute "Indonesia" for just about any close-to-third-world country with an internet connection and little or no government control of internet fraud (not that I'm really criticising of course, I'm sure such governments have much more important things to spend resources on).
It's a very close parallel to the spam situation.
If 90% of your spam originates in China and you have zero legitimate emails originating from China, then it's a no-brainer to just cut off the country. Same for intrusion attempts (as mentioned by another poster).
It's not saying that all Chinese or all Indonesians or all Ukranians or all Verio subscribers are spammers or fraudsters or crackers - just saying that, for a whole range of reasons, the overwhelming majority of those connecting to your server are spammers/fraudsters/crackers. So from that viewpoint.... *snip*;-).
I have a friend who works as a prosecutor (Perth, Western Australia). A while ago, he asked me if I had any thoughts re: breaking encryption - a case he was working on involved a guy with various encrypted files on his computer that they believed contained stolen credit card numbers. At the time, it would have been a "smoking gun" piece of evidence if they could get the passphrase out of him and prove what the files were.
But (surprisingly enough:)) the guy didn't want to help get himself convicted. And he was a CS grad and knew his shit with encryption, knew what he was doing well enough that it wasn't plausible to brute-force or otherwise "crack" the encryption. And of course the prosecution didn't exactly have a team of crypto-experts on call (which is one of the reasons my friend was bothering to ask me if I had any suggestions;-)).
I suggested to him that it was a pity they already had him in custody - if they'd still had him under surveillance, I would have suggested they stick a little keylogger device in his keyboard (ie. hardware, not software - exactly what you mentioned). Then you'd get his passphrase, you'd get pretty much everything needed. Regardless of operating system, regardless of the size/shape/colour/flavour of your encryption system. Unless you normally change keyboards every day or so, that'd pretty much cover all eventualities. Well, except for the "epoxy the case and peripheral access panels shut", and especially the "sleep with it and take it everywhere with you" techniques *grin*. But I get the impression that criminals that paranoid are rare - remember that every increase in "security" has a corresponding decrease in convenience.
Anyway, he seemed to think it a good idea, saying he'd have to remember that for future cases:). I'd heard of something like that being done in a case in the US, so presumed that the hardware issue was quite solvable. Frankly, I'd think it'd be much easier and more flexible in many cases to install software keyloggers (on a suspect's computer), but the hardware method would be much more reliable and harder to detect (as well as usable for all those inconvenient non-Windows computers:-)).
Hey, with God and Slashdot rooting for you, how could you not get better. ; )
So the plan is to slashdot God on Patrick's behalf? Well,
I hope God's got a few redundant pipes...:)
*pause*
Goddammit, I'm getting a 666 code - "invalid belief system". Looks like it's rejecting all requests
from non-theist clients. Hmmm... I wonder if I
can trick it by faking my user-agent...
The second is dead wrong- to ignore an exception, just catch all exceptions and do nothing. I know a lot of programmers who do just that to get rid of exceptions they can't fix.
Heh. Yeah, I've heard of that happening quite a lot in Java (not so much in C++, but still to some degree). There's two points I'd make about that:
To ignore an error/exceptional-condition indicated by the return code of a function, you literally don't have to do anything. You have to do something active to respond to the "message" indicated by the retval, but you don't have to do anything to ignore it.
With a C++-style exception (and, indeed, most exception systems I know of) you have to do something active to prevent an exception propagating further up the call stack. So you must do something in order to "ignore" an exception outcome - which effectively means that you're not ignoring it:).
It might seem like I'm splitting hairs here, but it is an important distinction.
Just catching exceptions and blithely going on as though nothing went wrong is not safe - no more than it's safe to ignore an error retval from a "normal" function. Programmers don't (normally:-)) throw pointless exceptions just for the hell of it. The whole point of a function throwing an exception is to indicate "I couldn't do what I'm supposed to do" and usually to give you some useful information as to why.
[AuMatar also said:]
Thats a bug in constructors, not a valid reason for exceptions.
Heh. I'll let you argue that point with Bjarne.:-)
In any case, if you really want to "return" a value from a constructor, you can do it in the same way you can for any other function with a void return type. You can add an extra reference parameter, eg.
void square(int a, int& retval) { retval = a*a; }
Yes, it's grotesque - but then so are many other cases where it's natural to return a single value from a function, but the user ends up having to check that returned value just to make sure it's not an error code. The common
thing with many POSIX functions being that a retval greater than or equal to zero is a valid return, while something less than zero (or specifically -1) indicates an error (the specific details of the error indicated by an external global variable).
The really nice thing (from my coding perspective) is that when the exception system is used properly, it really facilitates cleaner and clearer code. You can have functions for which the signatures are appropriate and make sense - and you don't have to tie yourself in a knot to handle exception/error situations appropriately.
I still think you haven't quite "got" the whole
point of exceptions (I'm not trying to say you're an idiot or anything, mind). I hoped the "Blub Paradox" pointer would indicate more effectively what I meant, but I guess not. If you'd done any programming with the Qt signal/slot system (or the similar-ish Boost.Signals library) you might have a better idea of how using an alternative control flow is a useful concept (though I'm probably drifting away from the main point now:).
I have a similar thing with continuations - I just don't get them, I can't understand what they're good for. I haven't yet found (and comprehended:)) an programming problem solved using continuations for which I couldn't see (what I thought to be) an equally elegant alternative solution.
But I'm willing to accept that there is something to them that I just can't see yet - if only because I'm quite happy to say that the kind of people involved in that sort of language design are almost certainly way way smarter than me.:)
Why am I doing it that way? Because its the one benefit exception people claim it gives them. If you catch after each line it is exactly like error codes. OF course its error codes with wird syntax and passing methods, so why not just use error codes?
Wow. What a strange response.
I don't know where you got the idea that "exception people" claim it's a benefit
that you can use exceptions in a way that's just as painful/limited as code using a return-error-code style (though even if you do that, they're still not exactly alike - the exception-throwing style still has advantages).
The major advantage of using exceptions (in my mind, at least) is that there is no need to use special return codes to signal errors. And there is no way to ignore an exception (as a coder can easily just not check a return code). And you
can handle an exception at the most appropriate
point in the call stack. And your code doesn't have to have a maze of return-code-checking logic after every single bloody might-possibly-return-an-error function call. And you can signal a failure even from a function that doesn't/can't return a value (eg. a constructor). And an exception object can carry arbitrary information along with it.
And cute furry animals and small children will trust you. Your gender-of-preference will find you more
attractive. You'll need less sleep and earn more money. Colours will seem brighter and the air fresher. Your google searches will work better.
The candidate you support will still lose the election, but hey, you can't expect everything:-).
Slightly more seriously, I think you might be suffering from a mild form of the Blub Paradox WRT exceptions (specifically C++ exceptions in this context). You may find it's
worth taking another look, because you are missing a lot if you think of exceptions as just a syntactically weird equivalent of return codes.
Just out of interest, what did you do? Did your NOC (whatever that is, I'm guessing your source of network connectivity) plug you back in a few hours later? Or are you still offline?
If the latter, I'm sort of impressed/scared at your willingness to remain offline (or change providers) rather than drop a single client (especially given you seem to be ready to accept that this client is a spammer, albeit not through your network). But I guess if he's been a no-problem client for two years, you'd probably find it a bit difficult to just kick him.
You say "If a critical revenue generating db goes down because of a bug a manager needs to be able to point their finger."
I thought Paul Graham put it perfectly:
This is the kind of possibility that the pointy-haired boss doesn't even want to think about. And so most of them don't. Because, you know, when it comes down to it, the pointy-haired boss doesn't mind if his company gets their ass kicked, so long as no one can prove it's his fault. The safest plan for him personally is to stick close to the center of the herd.
Within large organizations, the phrase used to describe this approach is "industry best practice." Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is "industry best practice," and the company loses, he can't be blamed. He didn't choose, the industry did.
I believe this term was originally used to describe accounting methods and so on. What it means, roughly, is don't do anything weird. And in accounting that's probably a good idea. The terms "cutting-edge" and "accounting" do not sound good together. But when you import this criterion into decisions about technology, you start to get the wrong answers.
(under the section "A Recipe")
Mind you, that kind of criterion is probably still quite valid in decisions about database technology - Graham was mainly discussing programming language technology in the aforementioned article.
But still, it's an interesting (albeit depressing) perspective - that the highest priority for a boss (whether pointy-haired or not) is to avoid blame for failure; not necessarily to avoid failure itself *wry grin*.
(BTW: I have no dispute whatsoever with your first point:-))
The reason he specifically mentioned the MSWindows TCP/IP stack being lifted from BSD UNIX should be pretty clear. The context was operating system code being copied from one OS to another. ESR was pointing out a well-known example of exactly that - an example that was only discovered/proved through behavioural analysis of the MSWindows TCP/IP stack... not through comparison of the two source code trees.
The opening sentence of that particular paragraph states the point he's making very clearly: "That a piece of code came from a proprietary vendor is no guarantee that it originated there." The point he's making is not relevant to code licensing, and especially not to the GPL. Sure, he could have mentioned any one of many many examples of GPL violations, but that'd just obscure the point (because then you're talking about a license violation as well, which you aren't in the MS/BSD example). And of course there aren't too many well-known examples of operating-system code being imported (legally or illegally) into a proprietary system (or at least not too many I know of, which isn't saying much;-).
It seems you saw a chance to take a swipe at Raymond and took it. You should have stayed focussed (on whatever point you were trying to make), but based on your apparent dislike of ESR I'm not sure you're capable of doing that.:)
It's a damn good thing I wasn't drinking anything right then, or I would be demanding compensation for my keyboard.;-)
To answer your very amusing question, though - yes. In fact, it's one of the best book reviews I've ever seen on slashdot. Perhaps a tad lengthy, but you can't have everything.
Did anyone else other than me who was doing MSVC6 projects in 1998 suddenly get real worried that this guy was stuck working on your old code?
ROTFL:):)
Just in case: Sorry, Pete. I can only claim extreme ignorance and inexperience, and offer you all my sympathy.
*mutters random Latin and waves hand* "You are forgiven, child. Say a dozen Hail Meyers, then go forth and sin no more."
*grin* Well, to be fair to whoever the basta^Wguy was, he did do it under fairly stressful conditions and he was in fact building the application based on some really horrendous mid-80's era C code. The sort of C code where you get stuff like: int tmp1, tmp2, tmp3, tmp4,...; Be afraid, be very afraid.
In fact, if I'd been in his position, I don't know that I would have done much better. *pause for thought* No, that's a complete lie, I would have done it much better. It still wouldn't have been all that good, but at least it'd be tolerable.
Sigh... which reminds me, I'd better get back to it. Arrrggh.
Thanks for the sympathy Fedallah, I appreciate it.;-)
Seriously dude, that is most definitely not a straightforward question. It's carefully designed to test your understanding of some of the subtle tricks and traps of C++. And one of the "tricks" it uses to mislead you has nothing to do with inheritance, rather with implicit casting.
I must admit I got tripped up on it though, mainly because I'd forgotten the distinction between hiding and overriding. The question is nasty, ugly, and was intended to be as confusing and tricky as possible... and any programmer that writes code like that (especially something involving changing the default value of a parameter for an overriden method) ought to be shot.
BTW, if you're asking questions out of GOTW as interview questions, I can only say that that's pretty nasty - except perhaps as a final round question for some of the really cocky smart-arse types:-). Or if you're looking for a seriously hard-core C++ expert, in which case you'd probably expect him/her to have read all of GOTW and Sutter's books and know all the answers off by heart anyway.
It seems most people who claim to be C++ programmers just say that because they use a C++ compiler and stick their functions in objects.
There's certainly a depressing number of such people about - though nowadays they're mainly moving into Java, a language better suited to their limitati^Wcapabilities. And I say "Hooray!" to that:).
Pete (who has for the last two months been maintaining/debugging/adding features to a 1998-era MSVC6 project, written by a guy who really had no idea about C++. Sigh.)
Naysayer - just a couple of questions, if you could answer.. I was puzzled by a couple of elements in your article, specifically to do with source control and build management, and how they relate.
(Note: quotes are directly from the article)
Lately, some companies have risen to provide asset control specifically for game projects. These tools are still far from ideal, but we have reason to hope that they will improve.
What exactly is there about game project "asset" control that is different from any other kind of software development asset control? If some software companies actually think it worthwhile to develop and sell tools specifically for game development, there must be something unusual about game development that makes traditional source control tools like Perforce or Bitkeeper less than ideal (and if the better tools are less than ideal, I can only imagine how bad the mediocre (CVS), the overengineered (ClearCase) or the really atrocious (SourceSafe) tools would be:-).
Otherwise:
During development we often have to build the game for all build types (Debug, Release) for all target platforms (PC, Playstation 2, Xbox) before committing our changes to source control.
That seems insane. You have to jump all those hoops before committing a simple code change on a single file?
So before a programmer can check in a batch of changes, they may need to perform between two and five full recompiles (which, as we mentioned earlier, sometimes take half an hour each!).
Full recompiles? In god's name, why? If you've changed a handful of files, all you should need to do is verify that those files compile+link+sort-of-work (before checking in to source control), surely...?
As in large business projects, bigger game teams tend to have a "build master," a person whose job is to watch over the build, ensuring that disruptions are remedied as quickly as possible. Sometimes pleasing the build master can be a difficult task. Yet despite the presence of a build master, builds still seem to be broken too often.
The sort of build management systems I'm used to involve scheduling a (usually automated) nightly build and battery of tests, performed on the latest code from the source control system (or perhaps on more than one branch in some cases).
If the tests (or the compile) fail, the job of the build master (usually by default the lead programmer) is to find out which developer(s) are responsible and get them to work out the problems.
The programmer's responsibilities are essentially just to verify that their code changes compile (and, preferably, do the right thing) before committing. But getting every programmer to test on all platforms, in both debug and release form, before committing any changes - that's just insane. So insane, in fact, that I'm really hoping I've completely misunderstood you and you don't really work like that... because it'd just lead to enormous time gaps between commits and massive pain when people have to routinely deal with significant code merging issues.
Please tell me I've misunderstood - or you were just exaggerating a bit for effect;-).
BTW, thanks for the article. Well-written and very interesting.
Slashdot Mirror
I can only say that it's going to be interesting when the Windows version of QT4 is available under the GPL and so most of KDE4 can (and will) be ported to Windows.
There are quite a few noteworthy KDE apps that punch well above their weight in comparison to Windows-only closed-source alternatives. K3B is one, apparently (I haven't used it), but I could see Konqueror (especially if people get the idea it's like Safari-for-Windows), KDevelop, Quanta and perhaps even KOffice and KMail getting a bit of attention.
If the company behind Nero is aware that K3B will be making an appearance on Windows eventually, they should be at least a bit concerned - especially if an ordinary user can come to the same conclusion as this reviewer ("Hmmm, nicer interface, much more usable, works fine, free...").
Of course, it'll mostly depend on whether your average Windows-only person ever becomes aware of the wide range of KDE4 software that they'll be able to install on their Windows machine. I suspect the KDE people wouldn't be that interested in an organised marketing effort at Windows users... but stranger things have happened. Anyway, word-of-mouth can be disturbingly effective. :)
*quavery voice* Whassat? Shpeak up!
You've missed the point. If a company sends you commercial propaganda email that you didn't specifically request - and you didn't give them permission to send (to you) - then they're spamming you.
You shouldn't ever ask a spammer to "remove" you from their list.... even if they did remove you (and some do) who would want to be in debt to a spammer? Alternatively, if enough people report them, they'll (sooner or later) get added to mainstream RBLs - then they can just sit there and wail "No no, you've got us all wrong, spamming is what other people do!" :-)
Yeah, they suck. Those low-id nerdy nerdlike nerd-people. Nerds.
I'm presuming this is some sort of weird troll, moderated "informative" for some odd reason (seriously moderator, "informative"? What derf?)
Seriously, if you think the Microsoft development tools are far superior to anything else in the world, then I can only presume you've never used anything else in the world :).
Ha. That's funny. WEBoggle was probably the major inspiration for the stuff I'm working on, when I first discovered it a few months ago. It's really a brilliant implementation of Boggle - so simple and enjoyable. Great fun.
Even though my partner is now dreadfully addicted to it :), I must thank you for making it. It's really cool.
When I have a bit more time I'm thinking of having a bash at implementing a Fungus clone using this sort of technology - there's probably a huge variety of simple-but-addictive games that'd be well suited to this kind of framework.
I'm working on a project at the moment that's all Javascript on the client side and mod_python (with the very nice Publisher handler on the server. I have a simple Javascript wrapper around XMLHttpRequest for making asynchronous calls to the server (using CPS with Javascript closures as the "continuations") and I just pass all the info back in JSON format, so I can just eval() the returned text.
Surprisingly neat and (very) surprisingly flexible - you can also do stuff like pass back Javascript functions (from the server) along with the data you wish to process.
You can use the Python str() function for the most simple data conversions (eg. an array or a dictionary), but I prefer the pyjsonrpc package which has very nice little objToJson and jsonToObj functions. Better than just using Python's str() function, as it also strips out excess whitespace. I also modified it slightly to also properly convert Python booleans to Javascript booleans (it already handled null to None conversions).
It all works very nicely, a testament to the power of simplicity. The Javascript (client) side just makes requests in response to user actions (eg. button clicks) or other events, and the server responds to those requests with Javascript data (CPS is very well suited to this kind of programming).
Javascript really is a very cool programming language. I've implemented my own python.js library which adds a handful of Python-like functional programming facilities to Javascript (eg. map, filter, reduce) and dictionary/object methods like keys() and values(). It's got to the point now where I sometimes get confused as to whether I'm writing Javascript or Python, because they're so similar in all the ways that really matter.
This kind of web development is quite fun. I also have a nice advantage with the web application I'm working on, as it flat-out can't run on IE (it uses fixed-positioned divs quite extensively, along with a few other standard features that IE can't handle) and so I don't have to worry about compatibility with that fucking mess of a browser. Hooray. :-)
The only reason you bother to press the "Submit" button on Slashdot is because you want someone else to read your words, true?
In that case, when you write you should care more about the people reading than yourself as the person writing. There are lots of conventions when writing English text - and while some are strange, there's a good reason for most of them. The reason for using capital letters at the start of sentences is fairly obvious - it helps to visually distinguish the start of a sentence.
Breaking the text into conceptual blocks (ie. paragraphs) is another thing that helps the reader and doesn't (necessarily) do anything for the writer (certainly if you're the kind of writer that doesn't bother to read your own words).
If you don't want to expend the trivial extra effort to follow basic conventions for written text, nobody's going to drag you up before the Literacy Police. Nobody's going to care. Because nobody's going to bother reading what you write.
Wow. I agree with Jericho4.0. Kids. And fairly stupid kids at that, several steps below your average script kiddie.
For some reason I'm very strongly reminded of this line :-).
Some of the bits from the article were pretty revealing too - one of the group members who was failing a CS degree because he never went to lectures and never studied (too busy "ripping and burning"). I'm guessing he didn't do the exams either :).
And of course, who could forget that very scary and extremely serious and realistic </sarcasm> threat to the author of the article: "You do not need some 350-pound hit man with a Glock at your front door." Someone's been living a bit too much in movie fantasy-land, methinks.
It's a song, "Rose Garden". The most famous and oft-repeated line from the song is "I never promised you a rose garden".
Credit card fraud.
Put it this way - you're just not going to be getting that many legitimate orders for high-end laptops from, say, Indonesia... at least compared to the blizzard of orders using stolen credit card numbers. It's much simpler and more cost-effective for the merchant to say "Nope, we just won't accept orders from $COUNTRIES."
Of course, feel free to substitute "Indonesia" for just about any close-to-third-world country with an internet connection and little or no government control of internet fraud (not that I'm really criticising of course, I'm sure such governments have much more important things to spend resources on).
It's a very close parallel to the spam situation. If 90% of your spam originates in China and you have zero legitimate emails originating from China, then it's a no-brainer to just cut off the country. Same for intrusion attempts (as mentioned by another poster).
It's not saying that all Chinese or all Indonesians or all Ukranians or all Verio subscribers are spammers or fraudsters or crackers - just saying that, for a whole range of reasons, the overwhelming majority of those connecting to your server are spammers/fraudsters/crackers. So from that viewpoint.... *snip* ;-).
I have a friend who works as a prosecutor (Perth, Western Australia). A while ago, he asked me if I had any thoughts re: breaking encryption - a case he was working on involved a guy with various encrypted files on his computer that they believed contained stolen credit card numbers. At the time, it would have been a "smoking gun" piece of evidence if they could get the passphrase out of him and prove what the files were.
But (surprisingly enough :)) the guy didn't want to help get himself convicted. And he was a CS grad and knew his shit with encryption, knew what he was doing well enough that it wasn't plausible to brute-force or otherwise "crack" the encryption. And of course the prosecution didn't exactly have a team of crypto-experts on call (which is one of the reasons my friend was bothering to ask me if I had any suggestions ;-)).
I suggested to him that it was a pity they already had him in custody - if they'd still had him under surveillance, I would have suggested they stick a little keylogger device in his keyboard (ie. hardware, not software - exactly what you mentioned). Then you'd get his passphrase, you'd get pretty much everything needed. Regardless of operating system, regardless of the size/shape/colour/flavour of your encryption system. Unless you normally change keyboards every day or so, that'd pretty much cover all eventualities. Well, except for the "epoxy the case and peripheral access panels shut", and especially the "sleep with it and take it everywhere with you" techniques *grin*. But I get the impression that criminals that paranoid are rare - remember that every increase in "security" has a corresponding decrease in convenience.
Anyway, he seemed to think it a good idea, saying he'd have to remember that for future cases :). I'd heard of something like that being done in a case in the US, so presumed that the hardware issue was quite solvable. Frankly, I'd think it'd be much easier and more flexible in many cases to install software keyloggers (on a suspect's computer), but the hardware method would be much more reliable and harder to detect (as well as usable for all those inconvenient non-Windows computers :-)).
Pete.So the plan is to slashdot God on Patrick's behalf? Well, I hope God's got a few redundant pipes... :)
*pause*
Goddammit, I'm getting a 666 code - "invalid belief system". Looks like it's rejecting all requests from non-theist clients. Hmmm... I wonder if I can trick it by faking my user-agent...
Heh. Yeah, I've heard of that happening quite a lot in Java (not so much in C++, but still to some degree). There's two points I'd make about that:
To ignore an error/exceptional-condition indicated by the return code of a function, you literally don't have to do anything. You have to do something active to respond to the "message" indicated by the retval, but you don't have to do anything to ignore it.
With a C++-style exception (and, indeed, most exception systems I know of) you have to do something active to prevent an exception propagating further up the call stack. So you must do something in order to "ignore" an exception outcome - which effectively means that you're not ignoring it :).
It might seem like I'm splitting hairs here, but it is an important distinction.
[AuMatar also said:]
Heh. I'll let you argue that point with Bjarne. :-)
In any case, if you really want to "return" a value from a constructor, you can do it in the same way you can for any other function with a void return type. You can add an extra reference parameter, eg.
void square(int a, int& retval) { retval = a*a; }
Yes, it's grotesque - but then so are many other cases where it's natural to return a single value from a function, but the user ends up having to check that returned value just to make sure it's not an error code. The common thing with many POSIX functions being that a retval greater than or equal to zero is a valid return, while something less than zero (or specifically -1) indicates an error (the specific details of the error indicated by an external global variable).
The really nice thing (from my coding perspective) is that when the exception system is used properly, it really facilitates cleaner and clearer code. You can have functions for which the signatures are appropriate and make sense - and you don't have to tie yourself in a knot to handle exception/error situations appropriately.
I still think you haven't quite "got" the whole point of exceptions (I'm not trying to say you're an idiot or anything, mind). I hoped the "Blub Paradox" pointer would indicate more effectively what I meant, but I guess not. If you'd done any programming with the Qt signal/slot system (or the similar-ish Boost.Signals library) you might have a better idea of how using an alternative control flow is a useful concept (though I'm probably drifting away from the main point now :).
I have a similar thing with continuations - I just don't get them, I can't understand what they're good for. I haven't yet found (and comprehended :)) an programming problem solved using continuations for which I couldn't see (what I thought to be) an equally elegant alternative solution.
But I'm willing to accept that there is something to them that I just can't see yet - if only because I'm quite happy to say that the kind of people involved in that sort of language design are almost certainly way way smarter than me. :)
Wow. What a strange response.
I don't know where you got the idea that "exception people" claim it's a benefit that you can use exceptions in a way that's just as painful/limited as code using a return-error-code style (though even if you do that, they're still not exactly alike - the exception-throwing style still has advantages).
The major advantage of using exceptions (in my mind, at least) is that there is no need to use special return codes to signal errors. And there is no way to ignore an exception (as a coder can easily just not check a return code). And you can handle an exception at the most appropriate point in the call stack. And your code doesn't have to have a maze of return-code-checking logic after every single bloody might-possibly-return-an-error function call. And you can signal a failure even from a function that doesn't/can't return a value (eg. a constructor). And an exception object can carry arbitrary information along with it. And cute furry animals and small children will trust you. Your gender-of-preference will find you more attractive. You'll need less sleep and earn more money. Colours will seem brighter and the air fresher. Your google searches will work better.
The candidate you support will still lose the election, but hey, you can't expect everything :-).
Slightly more seriously, I think you might be suffering from a mild form of the Blub Paradox WRT exceptions (specifically C++ exceptions in this context). You may find it's worth taking another look, because you are missing a lot if you think of exceptions as just a syntactically weird equivalent of return codes.
pacman -S mplayer
*shrug, grin*
(come on, how could anyone resist a distro with a package manager called "pacman"? :-)
Just out of interest, what did you do? Did your NOC (whatever that is, I'm guessing your source of network connectivity) plug you back in a few hours later? Or are you still offline?
If the latter, I'm sort of impressed/scared at your willingness to remain offline (or change providers) rather than drop a single client (especially given you seem to be ready to accept that this client is a spammer, albeit not through your network). But I guess if he's been a no-problem client for two years, you'd probably find it a bit difficult to just kick him.
(under the section "A Recipe")
Mind you, that kind of criterion is probably still quite valid in decisions about database technology - Graham was mainly discussing programming language technology in the aforementioned article.
But still, it's an interesting (albeit depressing) perspective - that the highest priority for a boss (whether pointy-haired or not) is to avoid blame for failure; not necessarily to avoid failure itself *wry grin*.
(BTW: I have no dispute whatsoever with your first point :-))
Ah, you don't really want to be 17 again.
No really, you don't.
(hey, if I can convince you, maybe I can convince myself... *grin*)
Pete (31st birthday in a week, argh).The reason he specifically mentioned the MSWindows TCP/IP stack being lifted from BSD UNIX should be pretty clear. The context was operating system code being copied from one OS to another. ESR was pointing out a well-known example of exactly that - an example that was only discovered/proved through behavioural analysis of the MSWindows TCP/IP stack... not through comparison of the two source code trees.
The opening sentence of that particular paragraph states the point he's making very clearly: "That a piece of code came from a proprietary vendor is no guarantee that it originated there." The point he's making is not relevant to code licensing, and especially not to the GPL. Sure, he could have mentioned any one of many many examples of GPL violations, but that'd just obscure the point (because then you're talking about a license violation as well, which you aren't in the MS/BSD example). And of course there aren't too many well-known examples of operating-system code being imported (legally or illegally) into a proprietary system (or at least not too many I know of, which isn't saying much ;-).
It seems you saw a chance to take a swipe at Raymond and took it. You should have stayed focussed (on whatever point you were trying to make), but based on your apparent dislike of ESR I'm not sure you're capable of doing that. :)
It's a damn good thing I wasn't drinking anything right then, or I would be demanding compensation for my keyboard. ;-)
To answer your very amusing question, though - yes. In fact, it's one of the best book reviews I've ever seen on slashdot. Perhaps a tad lengthy, but you can't have everything.
ROTFL :):)
*mutters random Latin and waves hand* "You are forgiven, child. Say a dozen Hail Meyers, then go forth and sin no more."
*grin* Well, to be fair to whoever the basta^Wguy was, he did do it under fairly stressful conditions and he was in fact building the application based on some really horrendous mid-80's era C code. The sort of C code where you get stuff like: int tmp1, tmp2, tmp3, tmp4, ...; Be afraid, be very afraid.
In fact, if I'd been in his position, I don't know that I would have done much better. *pause for thought* No, that's a complete lie, I would have done it much better. It still wouldn't have been all that good, but at least it'd be tolerable.
Sigh... which reminds me, I'd better get back to it. Arrrggh.
Thanks for the sympathy Fedallah, I appreciate it. ;-)
Pete.
Seriously dude, that is most definitely not a straightforward question. It's carefully designed to test your understanding of some of the subtle tricks and traps of C++. And one of the "tricks" it uses to mislead you has nothing to do with inheritance, rather with implicit casting.
I must admit I got tripped up on it though, mainly because I'd forgotten the distinction between hiding and overriding. The question is nasty, ugly, and was intended to be as confusing and tricky as possible... and any programmer that writes code like that (especially something involving changing the default value of a parameter for an overriden method) ought to be shot.
BTW, if you're asking questions out of GOTW as interview questions, I can only say that that's pretty nasty - except perhaps as a final round question for some of the really cocky smart-arse types :-). Or if you're looking for a seriously hard-core C++ expert, in which case you'd probably expect him/her to have read all of GOTW and Sutter's books and know all the answers off by heart anyway.
There's certainly a depressing number of such people about - though nowadays they're mainly moving into Java, a language better suited to their limitati^Wcapabilities. And I say "Hooray!" to that :).
Pete (who has for the last two months been maintaining/debugging/adding features to a 1998-era MSVC6 project, written by a guy who really had no idea about C++. Sigh.)Where's the "Score: 5, Ludicrously Funny" when you need it?
It might have been even more effective with a s/games/software/g , though.
Sigh. *roll of eyes*
Pete.Naysayer - just a couple of questions, if you could answer.. I was puzzled by a couple of elements in your article, specifically to do with source control and build management, and how they relate.
(Note: quotes are directly from the article)
What exactly is there about game project "asset" control that is different from any other kind of software development asset control? If some software companies actually think it worthwhile to develop and sell tools specifically for game development, there must be something unusual about game development that makes traditional source control tools like Perforce or Bitkeeper less than ideal (and if the better tools are less than ideal, I can only imagine how bad the mediocre (CVS), the overengineered (ClearCase) or the really atrocious (SourceSafe) tools would be :-).
Otherwise:
That seems insane. You have to jump all those hoops before committing a simple code change on a single file?
Full recompiles? In god's name, why? If you've changed a handful of files, all you should need to do is verify that those files compile+link+sort-of-work (before checking in to source control), surely...?
The sort of build management systems I'm used to involve scheduling a (usually automated) nightly build and battery of tests, performed on the latest code from the source control system (or perhaps on more than one branch in some cases).
If the tests (or the compile) fail, the job of the build master (usually by default the lead programmer) is to find out which developer(s) are responsible and get them to work out the problems.
The programmer's responsibilities are essentially just to verify that their code changes compile (and, preferably, do the right thing) before committing. But getting every programmer to test on all platforms, in both debug and release form, before committing any changes - that's just insane. So insane, in fact, that I'm really hoping I've completely misunderstood you and you don't really work like that... because it'd just lead to enormous time gaps between commits and massive pain when people have to routinely deal with significant code merging issues.
Please tell me I've misunderstood - or you were just exaggerating a bit for effect ;-).
BTW, thanks for the article. Well-written and very interesting.
Pete.