Visual Studio is widely renowned as the singular best programming environment there is
You've obviously never used slime on Emacs. Come to think of it, unless you feel like doing everything in basic or C++, Visual Studio pretty much sucks...
He could have used any of those, or all three. I don't see what he's complaining about. If you have a decent package management suite, it runs the checksums for you.
Geez... the lack of Quickbooks on Linux was a selling point for me. I prefer financial software that doesn't freeze, crash, and corrupt data randomly requiring a $200 per-incident call to someone in Bangalore just to be told that recover will cost another $500.
This is slightly OT I know, but desktop finance applications like that are a Bad Thing; for the price of your next Quickbooks upgrade, set up a web interface to a decently stable database and you're set.
This just in! "Hello world" has 0 bugs per three lines of code!
That's exactly the sort of attitude that lets bugs flourish. There's more than just the 3 lines in the "hello world" at stake: it's how those three lines interact with the system library, the kernel, and the environment that matters. Are you *certain* nothing in the platform lets a user launch the program in a way that accesses memory inappropriately? If so, how are you sure?
If you're doing this 20-30 times per 1000 lines, it's bound to show up pretty quick.
Well, yes and no. Some vulnerabilities can be found easily by static (and therefore theoretically automatable) code auditing. Some vulnerabilities can be found with difficulty by static code auditing. And some vulnerabilities (here is where Turing bites us) provably cannot be found by any computable process.
For instance, "format" bugs in functions are very easy to find: any time memory that has been touched by the user is processed as a format string, that is a vulnerability. These are easy to check for automatically. There are other times when the allocation and deletion of memory is ultimately determined by user input; this too represents a vulnerability but it is much more difficult to check because it requires instantiating a virtual arena runtime. Finally, there will always be conditions under which the result of any computational process cannot be determined beforehand (or as Rumsfeld would say, the "unknown unkowns"); to find these requires experience and intuition.
It's much more complex than considering the value of every variable you think is in scope. The environment, the OS, and the hardware all can affect a computation in ways that are difficult to predict.
A better solution is probably to distribute presentations as PDF format, and use Adobe Reader as the small viewer program.
Judging by the comments, am I the only person who uses OOo's feature of exporting slideshows as flash movies? Everyone else seems to do it as a pdf, which seems perverse to me.
Just for a few other examples, most people don't know that the windows command line allows redirection and pipes (">" and "|" just like you'd expect), has an almost fully-functional grep replacement (called "findstr"), and has a better "For" than bash.
Anyways, to answer grandparent, hosts is in that directory because the original winsock developers came from UNIX and changed as little of the layout as possible.
I used the names of some of my DND characters. Not in any dictionary, not spelled phonetically, but the way I liked to spell them. Unforgettable and unguessable.
Umm... unguessable except by the people you play D&D with...
So basicaly your little form just tells me you are a spammer. Perfectly tailored answer, no wonder you made it semi automatic & anonymous.
Sigh... that's not a spammer's joke; that form letter has been running around the anti-spam community for years as a reminder that there can't be a silver bullet to this problem.
There's no one killer app that's going to solve the spam problem. I think it will be solved, but gradually, over the next few years, through a broad spectrum of anti-spam techniques ranging from the technical (SPF) to the political (more spammers put behind bars) to the social (more user education that buying that neat radio-controlled car you got spammed about encourages spam).
As far as the particular merits of this solution, I think like all tarpit solutions it has its uses but they aren't universal. Contrary to a bullet point in the form letter, spammers do care about bad addresses in their lists, for three reasons:
They generally get paid per-click (only actual legal non-spamming companies have the credibility to get cash up-front per message sent). A bad server / bad address wastes their bandwidth sending to someone who can't make them any money.
Similarly, down servers or slow servers or bad addresses (depending on how the MX deals with them) slow down their own spamboxes. Remember, there are a few ultrarich spammers but most of these guys are on unbelievably tight margins.
Finally, their real money usually comes from list rentals and list sales. Bad addresses (or the reputation of bad addresses) cuts down on those rental values.
But I digress. The point is that this is, at best, one tool among many to ameliorate the spam problem. And pointing that out in a humurous way doesn't make grandparent post a spammer.
But isn't it that just those distributors are not necesary anymore now ?
Shhhhh.... don't say that too loud. That's actually what this whole fight is about: we don't need a record industry anymore. For about the same price as their instruments, musicians can rent (and, increasingly, buy) professional quality recording facilities. With the Internet, musicians can distribute their music on a pay or free basis for the cost of the van they drive to gigs.
Record companies aren't worried about lost album sales from filesharing. If anything, they probably appreciate the increased sales it brings. What record companies are worried about is that musicians can get exposure without signing a contract. That's what this is about, and how this fight goes will determine a lot about the kind of future working musicians will have for the next decade or so.
Therefore, there's not much parents can do to protect their kids from watching broadcast TV.
Ummm... except for not letting children watch tv by themselves. The TV is not a babysitter. And if these parents can't trust their kids to follow rules like, "don't watch tv when you're at home alone" maybe those parents need to re-think the priorities that led them to have both parents out of the house for a large part of the day. Just a thought.
So, when Shekhem came in from the fields having been gored by an ox, do you think he would say, "Ouch, I think I broke a non-specific bone on the left side of my torso for which we have not seen fit to make up a word"?
Personally it would not surprise me, since I do not think that ancient languages would have advanced anatomy words.
Ummm... why not? Anatomy is exactly the sort of vocabulary I would expect them to have. And "rib" is hardly "advanced anatomy". And at any rate, the Egyptians and Babylonians could do successful brain surgery (not just "drilling holes in the head to let the evil spirits out", but successfully brain swellings); Galen inherited his anatomical knowledge pretty much complete and was just the first to publish it in a comprehensive set of works.
I don't know much ancient Hebrew, but there is definitely a word for "rib" in ancient Egyptian and in early Arabic, so I would be very surprised if Hebrew were different.
and thus 500 years ago - when the temperatures were exactly the same as they were in 2003 according to this information - then fossil fuels were to blame then
Umm.... TFA says nothing of the sort. It says this was "almost undoubtedly" the hottest summer in Europe in over 500 years, and doesn't explain the data.
Now, it's possible your interpretation is right, that 1503 was as hot as 2004. It's also possible that we've only been able to measure air temperature with something like reliability for about 500 years. It's like when we say the school violence rate is the lowest it's been since 1963: that doesn't neccessarily mean the rate was higher in 1962, it just means we started keeping records in 1963.
TFA does, however, reference the fact that air temperature have been demonstrably rising for at least 5 decades now.
The Common Lisp standard library offers "just about everything" except sockets, threads, a relational database API, a GUI API, standard HTTP/FTP/XML-RPC libraries, XML libraries, cryptographic libraries, imaging libraries, and the list goes on.
Eh... as long as you're sticking with a given implementation you have all that, and most of it is pretty good.
For that matter, nowadays if you're using lisp in a production environment you're pretty much using one of: Allegro, CMU-CL, or SBCL. They each have their own implementation of the libraries you mentioned. And anyways there's a good Allegro/CMU compatability layer and SBCL is compatible with CMU natively. ASDF solved a lot of these library problems.
htmlgen, odbc, postgres, gtk, sdl, opengl, blowfish, twofish, aes, des, md5, elgamal, irc, tcpip, sockets, and of course ffi: I have all of those installed on my lisp boxes, and they do what they say they do. Now, when I'm working with Forth, that's a different story...
Got my license 7 years ago. I moonlight sometimes in a local warehouse. Also nice to know it's a way I could get money if this IT thing ever totally falls through.
Considering this, what security measures are taken to protect data from the superusers?
Dual auditing. My activity is logged by a system I have no control over, and that other admin is logged by my system. It's true there are ways I could cover my tracks but it would be apparent I had hidden something even if they couldn't tell what I hid. At which point my ass would no longer be covered (logging has advantages for both sides in that sense), and I'd be asking if you want fries with that.
The short answer is that it's altered the TCP/IP stack and the SP2 updater doesn't check for that.
I've seen it 3 times now: SP2 is installed, machine reboots, and the machine can no longer make TCP connections. ICMP works fine, UDP works fine, so presumably IP itself works fine, but TCP connections stop working. Repair reinstall didn't work, but overlay reinstall did. Go figure.
My understanding of the FHS is that/usr/bin should be for important core utilities that are (or pratically are) part of the OS, not random applications.
Well... that may be what FHS says, but that goes against the tradition that the distros are following, namely:
/bin: the binaries you need to have to boot and init
/sbin: the binaries you need to have to boot that only root should be able to even know about.
/usr/bin: the binaries you don't need to have to boot and init, that you got through your vendor's bundling / package management.
/usr/sbin: binaries from your vendor that only root should be able to even know about.
/usr/local/(bin|sbin|etc|var|lib): a little miniature filesystem for all the stuff that you didn't get from your vendor.
You're exactly right: the distros leave/usr/local empty because that's what it's there for: a place for your own stuff so that it and the distro's stuff don't get in each other's way.
Slashdot Mirror
You've obviously never used slime on Emacs. Come to think of it, unless you feel like doing everything in basic or C++, Visual Studio pretty much sucks...
He could have used any of those, or all three. I don't see what he's complaining about. If you have a decent package management suite, it runs the checksums for you.
Geez... the lack of Quickbooks on Linux was a selling point for me. I prefer financial software that doesn't freeze, crash, and corrupt data randomly requiring a $200 per-incident call to someone in Bangalore just to be told that recover will cost another $500.
This is slightly OT I know, but desktop finance applications like that are a Bad Thing; for the price of your next Quickbooks upgrade, set up a web interface to a decently stable database and you're set.
That's exactly the sort of attitude that lets bugs flourish. There's more than just the 3 lines in the "hello world" at stake: it's how those three lines interact with the system library, the kernel, and the environment that matters. Are you *certain* nothing in the platform lets a user launch the program in a way that accesses memory inappropriately? If so, how are you sure?
Well, yes and no. Some vulnerabilities can be found easily by static (and therefore theoretically automatable) code auditing. Some vulnerabilities can be found with difficulty by static code auditing. And some vulnerabilities (here is where Turing bites us) provably cannot be found by any computable process.
For instance, "format" bugs in functions are very easy to find: any time memory that has been touched by the user is processed as a format string, that is a vulnerability. These are easy to check for automatically. There are other times when the allocation and deletion of memory is ultimately determined by user input; this too represents a vulnerability but it is much more difficult to check because it requires instantiating a virtual arena runtime. Finally, there will always be conditions under which the result of any computational process cannot be determined beforehand (or as Rumsfeld would say, the "unknown unkowns"); to find these requires experience and intuition.
It's much more complex than considering the value of every variable you think is in scope. The environment, the OS, and the hardware all can affect a computation in ways that are difficult to predict.
init runs as pid negative 1 on your computer?
And non-root users can kill init? Interesting OS
Judging by the comments, am I the only person who uses OOo's feature of exporting slideshows as flash movies? Everyone else seems to do it as a pdf, which seems perverse to me.
Maybe that's why OOo exports slideshows to flash, not to pdf?
I can halfway buy that, but if that's the case where is McCarthy? Where is Chuck Moore? Grace Hopper? Larry Wall?
Just for a few other examples, most people don't know that the windows command line allows redirection and pipes (">" and "|" just like you'd expect), has an almost fully-functional grep replacement (called "findstr"), and has a better "For" than bash.
Anyways, to answer grandparent, hosts is in that directory because the original winsock developers came from UNIX and changed as little of the layout as possible.
Beneath the cruft of Windows, within the [windows|winnt]\system32 directory, there lurks a roughly POSIX system, including such files as /etc/hosts.
That is not a small number!
That is a very big number!!
Umm... unguessable except by the people you play D&D with...
Sigh... that's not a spammer's joke; that form letter has been running around the anti-spam community for years as a reminder that there can't be a silver bullet to this problem.
There's no one killer app that's going to solve the spam problem. I think it will be solved, but gradually, over the next few years, through a broad spectrum of anti-spam techniques ranging from the technical (SPF) to the political (more spammers put behind bars) to the social (more user education that buying that neat radio-controlled car you got spammed about encourages spam).
As far as the particular merits of this solution, I think like all tarpit solutions it has its uses but they aren't universal. Contrary to a bullet point in the form letter, spammers do care about bad addresses in their lists, for three reasons:
But I digress. The point is that this is, at best, one tool among many to ameliorate the spam problem. And pointing that out in a humurous way doesn't make grandparent post a spammer.
Shhhhh.... don't say that too loud. That's actually what this whole fight is about: we don't need a record industry anymore. For about the same price as their instruments, musicians can rent (and, increasingly, buy) professional quality recording facilities. With the Internet, musicians can distribute their music on a pay or free basis for the cost of the van they drive to gigs.
Record companies aren't worried about lost album sales from filesharing. If anything, they probably appreciate the increased sales it brings. What record companies are worried about is that musicians can get exposure without signing a contract. That's what this is about, and how this fight goes will determine a lot about the kind of future working musicians will have for the next decade or so.
Ummm... except for not letting children watch tv by themselves. The TV is not a babysitter. And if these parents can't trust their kids to follow rules like, "don't watch tv when you're at home alone" maybe those parents need to re-think the priorities that led them to have both parents out of the house for a large part of the day. Just a thought.
So, when Shekhem came in from the fields having been gored by an ox, do you think he would say, "Ouch, I think I broke a non-specific bone on the left side of my torso for which we have not seen fit to make up a word"?
Ummm... why not? Anatomy is exactly the sort of vocabulary I would expect them to have. And "rib" is hardly "advanced anatomy". And at any rate, the Egyptians and Babylonians could do successful brain surgery (not just "drilling holes in the head to let the evil spirits out", but successfully brain swellings); Galen inherited his anatomical knowledge pretty much complete and was just the first to publish it in a comprehensive set of works.
I don't know much ancient Hebrew, but there is definitely a word for "rib" in ancient Egyptian and in early Arabic, so I would be very surprised if Hebrew were different.
Umm.... TFA says nothing of the sort. It says this was "almost undoubtedly" the hottest summer in Europe in over 500 years, and doesn't explain the data.
Now, it's possible your interpretation is right, that 1503 was as hot as 2004. It's also possible that we've only been able to measure air temperature with something like reliability for about 500 years. It's like when we say the school violence rate is the lowest it's been since 1963: that doesn't neccessarily mean the rate was higher in 1962, it just means we started keeping records in 1963.
TFA does, however, reference the fact that air temperature have been demonstrably rising for at least 5 decades now.
Maybe. Then again I haven't worked at a site that used Windows since 2001. Different perspectives I guess.
Eh... as long as you're sticking with a given implementation you have all that, and most of it is pretty good.
For that matter, nowadays if you're using lisp in a production environment you're pretty much using one of: Allegro, CMU-CL, or SBCL. They each have their own implementation of the libraries you mentioned. And anyways there's a good Allegro/CMU compatability layer and SBCL is compatible with CMU natively. ASDF solved a lot of these library problems.
htmlgen, odbc, postgres, gtk, sdl, opengl, blowfish, twofish, aes, des, md5, elgamal, irc, tcpip, sockets, and of course ffi: I have all of those installed on my lisp boxes, and they do what they say they do. Now, when I'm working with Forth, that's a different story...
Got my license 7 years ago. I moonlight sometimes in a local warehouse. Also nice to know it's a way I could get money if this IT thing ever totally falls through.
Dual auditing. My activity is logged by a system I have no control over, and that other admin is logged by my system. It's true there are ways I could cover my tracks but it would be apparent I had hidden something even if they couldn't tell what I hid. At which point my ass would no longer be covered (logging has advantages for both sides in that sense), and I'd be asking if you want fries with that.
That's how my shop does it at least.
The short answer is that it's altered the TCP/IP stack and the SP2 updater doesn't check for that.
I've seen it 3 times now: SP2 is installed, machine reboots, and the machine can no longer make TCP connections. ICMP works fine, UDP works fine, so presumably IP itself works fine, but TCP connections stop working. Repair reinstall didn't work, but overlay reinstall did. Go figure.
Well... that may be what FHS says, but that goes against the tradition that the distros are following, namely:
You're exactly right: the distros leave /usr/local empty because that's what it's there for: a place for your own stuff so that it and the distro's stuff don't get in each other's way.