No, I'm serious. Wily is one of the neatest editors I've ever used. The whole "arbitrary text is active menu-buttons-ish" interface is still quite a departure from the rest of the interface world, and a refreshing one, too.
Tribes 2, for example, where one side can win when they're all playing lone cowboys, but a side playing as a team will completely crush them, even if the team is outnumbered. The obvious examples: some of the weapons aren't really effective unless you have a teammate with a targeting laser. Most of the vehicles require multiple people on board to be anything other than a way to get from A to B.
You can access all your personally identifiable information that we collect online and maintain by [description of the company access procedure]. We use this procedure to better safeguard your information.
No, the square brackets are not editing on my part. That's what it actually says.:-)
The coverage of exceptions -- an equally if not more important topic than templates -- is almost non-existant. That was a great disappointment, [...]
I disagree that exceptions are more important than templates. Equally important, okay. *grin* (I would point out that exceptions have been done in other languages, while C++'s templates offer things which no other languages' type-parametric features do.) But that's neither here nor there.
I do agree with you about the lack of exception coverage; that would have been nice to see. (But remember the 300-page limit. Something would have had to get dropped in order to fit exceptions in.)
I don't know which chapter I would have dropped if I were them... any suggestions?
I think the book is much better for those who've programmed in other languages and then come to C++ than for beginners.
Absolutely. They don't even try to explain concepts like "variables" and other high-school-algebra or cs101-ish topics. They assume you know that programs have to be written in a "programming language," that we can't simply write in English instructions, etc. Some kind of programming background is assumed. (Again, 300 pages.)
Finally, it's written by the in-crowd. Many of the reviews were also written by the in-crowd.
Odd, that's precisely why I bought the book. "Written by experts who have been heavily involved since the beginning... okay, that getsa few more points in my book. *reads reviews* All the really really intelligent non-fluffy C++ gurus also recommend it... even more points... okay, I'll try it." And I read every word, even though I've years of experience with C++. And I was amazed.
if you're going the 'don't need to understand 'C', pointer-free,
Bzzzt. Go back and read it again.
The idea is that you don't have to learn C before learning C++. That you don't have to learn pointers before learning dynamic expansion of storage. You've conveniently forgotten the last bits.
Nobody ever said anything about not learning these things at all, not learning the entire language. That'd be stupid.
To me, the STL was like putting lipstick on a garbage can. It may look prettier now but I'm still never going to kiss it. It's still something you have to wrangle, bang around and not look at when you don't have to.
Fortunately, you're in the incorrect minority. Most people who feel like that had a bad experience with the STL, back before it was standardized, before the language itself was changed to make things easier. Since then they've
found that it's much better than they first thought.
...should, I have decided, always involve the text Accelerated C++, by Koenig and Moo. They have been working with C++ since its inception, down the hall from Stroustrup.
The book takes two relatively new approaches to teaching C++: 1) don't teach C first, and 2) assume that the standard C++ library is there. So, they introduce "Hello, World" using std::string and std::cout, and they keep using std::string without trying to first teach template classes with default template parameters. The resulting intro programs are very clean and simple, easy to follow.
The word "pointer" isn't even mentioned until chapter 9. By that point, they're using strings and vectors to solve useful programs, and since both of those containers manage memory themselves, the user needs to know nothing about dynamic memory management (and thus, pointers) before doing the exercises.
Pointers and user-defined types are introduced, of course, but they don't need to be introduced before showing the reader how to use the basic library features. You don't need to know how an internal combustion engine works before learning how to drive, although going back later and learning what's under the hood will always reward the observant driver.
This approach has gotten rave reviews, and from actual C++ people, not just fluff reviewers. It's the produce of years of teaching C++ courses.
Final note: the book is one of the fantastic "C++ In-Depth" series, of which Stroustrup is the series editor. All are very high quality. One of the series' rules is that the main body of the book can be no more than 300 pages, so "make your point, make it simple, make it clear" rules the day.
I shattered my lower left leg. Recovery has been very, very good, but I still have a small pin/screw through the ankle. The rate of expansion/contraction of [whatever material it is, probably surgical steel] is not quite the same as that of bone, because on hot and humid days like today, that ankle hurts like a sonuvabitch.
The surgeon and all the staff told me I would probably be able to predict thunderstorms for as long as I have the pin in, but would also be going through a tad more Advil than normal.:-)
...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring/usr, or accidentally damaging the dynamic loader, or still functioning while restoring dynamic libs from tape, etc, etc.
Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.
It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.
If you're talking about the viruses that simply "infect all Word files it can find, even on network shares," for example, then running Samba instead of Windows makes no difference. The infected client simply sees a share like any other -- that being the whole point, after all. The Samba server simply sees a write request like any other.
So yes, files shared via Samba can be infected, if it's that kind of virus.
Exploits that try to break into a Windows file server directly (as opposed to writing to exported files) will almost certainly fail for what I hope are obvious reasons.
And the average/. reader is probably also cylidrically shaped, too, just like the canisters.
When dropped from a height, if your first reactions are to stand up, contact other geeks, and begin finding local networks, then yes, Uncle Sam Wants You!
My Windows box has one network card. It is thus both "the internet interface" as well as the connection to the "corporate network". As well as everything else.
Why are you surprised that the RPC can't tell the difference? There's only one interface.
This isn't so much about security as it is poor design on the part of microsoft leaving so many useless services exposed to the internet.
That's either a great troll or a thoughtless statement. Tell me, in precise detail, how Microsoft is supposed to expose the RPC service to the local corporate network (where it is not "useless" by any means) but not expose the same service to "the internet". On a single network card.
There are two solutions to the RPC problem: have the corporate router block RPC from outside -- which has nothing to do with your machine -- and/or install a packet filter on the local system to drop RPC requests not coming from corporate systems. How Microsoft is supposed to magically know what those corporate systems are during installation, of course, is a pesky minor detail that we don't like to mention on/.
SGI was doing the lava-lamp-interpret-image random-number thing several years ago. I first saw the project website when I was an undergrad, when it was hosted at some-odd-name.sgi.com/~some-employee/spare-time-pr ojects/freaky-weird/lava.html.
I think they've changed the arrangements/colors of the lamps since then, but it's not new.
They do have more than one sysadmin, but none of them are full-time, I believe.
There are also some "interesting" schools of thought regarding security over in gnu.org land, and I'm sure there's tension between them as well. For example, savannah has to have some level of security, but their shell machine (not savannha) has almost zero "sysadmin-added" security: important configuration files are world-writable[*], because RMS doesn't believe in restricting individual actions of users on that machine. The only security is what's provided by the default installation, minus the world-writabilities.
So it should come as no suprise that the shell machine has been compromised multiple times. All from local users exploiting holes. The most recent was done in April, but they didn't find out about it until a few weeks ago. They're still recreating accounts.
I don't know about the ftp machine; I assume it's neither the same system as savannah nor the shell box. But it wouldn't surprise me to find the same situation: some important people gnu.org don't believe in locking down machines, some important people do, but (gripping hand) it almost doesn't matter because none of them have the time to do so.
(If you wonder why the GCC manuals, web pages, etc, on {savannha,www,ftp}.gnu.org are occasionally out of date, it's because gcc.gnu.org (the master) is not admin'd by the same group. Events like this are why it's not admin'd by the same group.)
[*] Backups are done by having little Emacs hooks in comments in the files. When you edit the file -- and of COURSE you're using GNU/FSF Emacs, not XEmacs or any other editor in the world, cuz it's a gnu.org machine -- Emacs knows to make backup copies. I have no idea whether real backups are done, or how.
Any contribution coming from anybody related to SCO should be seen with extreme paranoid suspicion and skepticism.
Because SCO has always been our enemy. Just like Iraq has always been our enemy, and Russia has always been our ally.
For those of you who have been reading your Corrected History books, pull your heads out of your ass and look at actual archives. The port maintainer in question has been contributing code for a long, long time. In good faith. With a smile, even. He has the same copyright assignment on file as the rest of the GCC contributors, which means SCO signed a disclaimer that they would not try to claim ownership of the code he contributes, just like every other software-related company whose employees contribute code to GCC.
but the safety of GCC is owrth alienating one guy if you ask me.
Fortunately, nobody has to ask you, because you're wrong.
(People bitch and moan about GCC contributors being required to get assignments and disclaimers from their employer. This is one of the reasons why it's done. It's different from other open source projects, but/. has overlooked that fact)
You don't need to have contributed a single line of code to GCC in order to arrive to this conclussion.
No, but you do need to be completely ignorant of the rules by which GCC operates.
Feh. I submitted this story the day it happened, with a better writeup, too. I forgot my name's in the auto-rejector. Anyhow...
Call it a cleanup or refactoring. GCC removes support for obsolete archs all the time.
This was discussed on the GCC lists, and rejected. The obsoletion procedure (announce deprecation in release X, remove support in X+1 if nobody steps up to maintain it) would be completely inappropriate for this case. The SCO platform is still actively maintained. It would also turn the obsoletion rule into a political one, instead of a purely technical one like it is now.
Okay, fine, you may say, then don't use the obsoletion rules, use new ones. But the obsoletion rules are, at present, the one ones which permit the GCC maintainers to drop support for platforms wholesale. It's the FSF who makes the political decisions, not the maintainers.
Re:i386, MC68000 and others obseleted?
on
GCC 3.3.1 Released
·
· Score: 2, Informative
That's a good troll, and it would be funny, except that every time someone tries these jokes on/., they turn into outraged flamage on the GCC development lists.
How am I going to compile stuff for my old 68K (Mac)
If you care that much, provide the support in GCC. Either write the code yourself, or convince/hire someone else to do it for you. They've gone supported for a long time now, which means that nobody cares enough.
If you care, but not quite enough, then use an older compiler.
and '386 machines now?
Ha, ha. You conveniently ommitted the "Windows NT 3.x" part of the obsoletion name.
Re:Oops, and there goes varargs.h...
on
GCC 3.3.1 Released
·
· Score: 1, Insightful
Because maintaining it was a pain in the ass, and blocked the fixing of other bugs.
If you must compile older code, rather then a newer version of that code, then use an older compiler.
Re:a clone of a horse is a horse, of course,of cou
on
Scientists Clone Horse
·
· Score: 0, Redundant
A horse is a horse, of course, of course.
A Jedi horse, he uses the Force.
His favorite code to use is Morse.
He's the famous Mister Ed!
From goats.com, one of the funniest comic strips on the web. (Hint: read the "kittens = poptarts" series from their archives.)
No, I don't live in a small podunk town. Sorry to disappoint you. But neither do I live in California, and that's where your misunderstanding lies.
Your analogy shoots yourself in the foot. If I go to the Castro district and 11 out of 12 are gay, you are correct, I can't extrapolate that to the rest of the world.
Likewise, if I go to the middle of Silicon Valley and the judges there know about Linux, I can't extrapolate that to the rest of the world either. Or even the rest of the country. People at large are not as tech-savvy as people in Silicon Valley. That judge is the exception, not the rule.
If you don't agree, if you feel Silicon Valley is the American norm and everywhere else is podunk, well, your opinion is your opinion. I disagree. And I think we can leave it at that. If you'd like to make more childish comments about professional lawyers "not knowing what the fuck is going on" because they happen to not live in California, go right ahead.
It's not sterotypes. It's statistics. 11 out of the 12 people I know in law offices have never heard of Linux. Three of them say that their colleagues (they didn't say how many, unfortunately) at other law offices have never heard of Linux either.
From that, I extrapolate that -- again, read this slowly, since you seem to have trouble with the concept -- it's a safe bet that the average person in a law office does not currently know of Linux. So, we need to get the word out.:-)
Nothing about eliteness, or snobbery, or sterotypes. Sorry if that offends you.
Slashdot Mirror
I felt obligated to say that.
No, I'm serious. Wily is one of the neatest editors I've ever used. The whole "arbitrary text is active menu-buttons-ish" interface is still quite a departure from the rest of the interface world, and a refreshing one, too.
Tribes 2, for example, where one side can win when they're all playing lone cowboys, but a side playing as a team will completely crush them, even if the team is outnumbered. The obvious examples: some of the weapons aren't really effective unless you have a teammate with a targeting laser. Most of the vehicles require multiple people on board to be anything other than a way to get from A to B.
From their "Info" page:
No, the square brackets are not editing on my part. That's what it actually says. :-)
I might just drop him a polite word...
I disagree that exceptions are more important than templates. Equally important, okay. *grin* (I would point out that exceptions have been done in other languages, while C++'s templates offer things which no other languages' type-parametric features do.) But that's neither here nor there.
I do agree with you about the lack of exception coverage; that would have been nice to see. (But remember the 300-page limit. Something would have had to get dropped in order to fit exceptions in.) I don't know which chapter I would have dropped if I were them... any suggestions?
Absolutely. They don't even try to explain concepts like "variables" and other high-school-algebra or cs101-ish topics. They assume you know that programs have to be written in a "programming language," that we can't simply write in English instructions, etc. Some kind of programming background is assumed. (Again, 300 pages.)
Odd, that's precisely why I bought the book. "Written by experts who have been heavily involved since the beginning... okay, that getsa few more points in my book. *reads reviews* All the really really intelligent non-fluffy C++ gurus also recommend it... even more points... okay, I'll try it." And I read every word, even though I've years of experience with C++. And I was amazed.
Bzzzt. Go back and read it again.
The idea is that you don't have to learn C before learning C++. That you don't have to learn pointers before learning dynamic expansion of storage. You've conveniently forgotten the last bits.
Nobody ever said anything about not learning these things at all, not learning the entire language. That'd be stupid.
Fortunately, you're in the incorrect minority. Most people who feel like that had a bad experience with the STL, back before it was standardized, before the language itself was changed to make things easier. Since then they've found that it's much better than they first thought.
...should, I have decided, always involve the text Accelerated C++, by Koenig and Moo. They have been working with C++ since its inception, down the hall from Stroustrup.
The book takes two relatively new approaches to teaching C++: 1) don't teach C first, and 2) assume that the standard C++ library is there. So, they introduce "Hello, World" using std::string and std::cout, and they keep using std::string without trying to first teach template classes with default template parameters. The resulting intro programs are very clean and simple, easy to follow.
The word "pointer" isn't even mentioned until chapter 9. By that point, they're using strings and vectors to solve useful programs, and since both of those containers manage memory themselves, the user needs to know nothing about dynamic memory management (and thus, pointers) before doing the exercises.
Pointers and user-defined types are introduced, of course, but they don't need to be introduced before showing the reader how to use the basic library features. You don't need to know how an internal combustion engine works before learning how to drive, although going back later and learning what's under the hood will always reward the observant driver.
This approach has gotten rave reviews, and from actual C++ people, not just fluff reviewers. It's the produce of years of teaching C++ courses.
Final note: the book is one of the fantastic "C++ In-Depth" series, of which Stroustrup is the series editor. All are very high quality. One of the series' rules is that the main body of the book can be no more than 300 pages, so "make your point, make it simple, make it clear" rules the day.
...like, implanted medical equipment.
I shattered my lower left leg. Recovery has been very, very good, but I still have a small pin/screw through the ankle. The rate of expansion/contraction of [whatever material it is, probably surgical steel] is not quite the same as that of bone, because on hot and humid days like today, that ankle hurts like a sonuvabitch.
The surgeon and all the staff told me I would probably be able to predict thunderstorms for as long as I have the pin in, but would also be going through a tad more Advil than normal. :-)
(I'm not complaining. I'm alive and can walk!)
Determine the first "casual Friday" and follow its migration around the country.
...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring
Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.
It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.
If you're talking about the viruses that simply "infect all Word files it can find, even on network shares," for example, then running Samba instead of Windows makes no difference. The infected client simply sees a share like any other -- that being the whole point, after all. The Samba server simply sees a write request like any other.
So yes, files shared via Samba can be infected, if it's that kind of virus.
Exploits that try to break into a Windows file server directly (as opposed to writing to exported files) will almost certainly fail for what I hope are obvious reasons.
Exactly. Gardeners call it pruning. It's a sign of healthy, normal growth.
is the one in the Rotten Library entry for North Korea.
And the average
When dropped from a height, if your first reactions are to stand up, contact other geeks, and begin finding local networks, then yes, Uncle Sam Wants You!
My Windows box has one network card. It is thus both "the internet interface" as well as the connection to the "corporate network". As well as everything else.
Why are you surprised that the RPC can't tell the difference? There's only one interface.
That's either a great troll or a thoughtless statement. Tell me, in precise detail, how Microsoft is supposed to expose the RPC service to the local corporate network (where it is not "useless" by any means) but not expose the same service to "the internet". On a single network card.
There are two solutions to the RPC problem: have the corporate router block RPC from outside -- which has nothing to do with your machine -- and/or install a packet filter on the local system to drop RPC requests not coming from corporate systems. How Microsoft is supposed to magically know what those corporate systems are during installation, of course, is a pesky minor detail that we don't like to mention on /.
You, sir, either owe me the cost of a new keyboard, or need to come over hear and clean the coffee out of the keyboard yourself.
That was the funniest damn thing I've read all week.
SGI was doing the lava-lamp-interpret-image random-number thing several years ago. I first saw the project website when I was an undergrad, when it was hosted at
some-odd-name.sgi.com/~some-employee/spare-time-p
I think they've changed the arrangements/colors of the lamps since then, but it's not new.
They do have more than one sysadmin, but none of them are full-time, I believe.
There are also some "interesting" schools of thought regarding security over in gnu.org land, and I'm sure there's tension between them as well. For example, savannah has to have some level of security, but their shell machine (not savannha) has almost zero "sysadmin-added" security: important configuration files are world-writable[*], because RMS doesn't believe in restricting individual actions of users on that machine. The only security is what's provided by the default installation, minus the world-writabilities.
So it should come as no suprise that the shell machine has been compromised multiple times. All from local users exploiting holes. The most recent was done in April, but they didn't find out about it until a few weeks ago. They're still recreating accounts.
I don't know about the ftp machine; I assume it's neither the same system as savannah nor the shell box. But it wouldn't surprise me to find the same situation: some important people gnu.org don't believe in locking down machines, some important people do, but (gripping hand) it almost doesn't matter because none of them have the time to do so.
(If you wonder why the GCC manuals, web pages, etc, on {savannha,www,ftp}.gnu.org are occasionally out of date, it's because gcc.gnu.org (the master) is not admin'd by the same group. Events like this are why it's not admin'd by the same group.)
[*] Backups are done by having little Emacs hooks in comments in the files. When you edit the file -- and of COURSE you're using GNU/FSF Emacs, not XEmacs or any other editor in the world, cuz it's a gnu.org machine -- Emacs knows to make backup copies. I have no idea whether real backups are done, or how.
Because SCO has always been our enemy. Just like Iraq has always been our enemy, and Russia has always been our ally.
For those of you who have been reading your Corrected History books, pull your heads out of your ass and look at actual archives. The port maintainer in question has been contributing code for a long, long time. In good faith. With a smile, even. He has the same copyright assignment on file as the rest of the GCC contributors, which means SCO signed a disclaimer that they would not try to claim ownership of the code he contributes, just like every other software-related company whose employees contribute code to GCC.
Fortunately, nobody has to ask you, because you're wrong.
(People bitch and moan about GCC contributors being required to get assignments and disclaimers from their employer. This is one of the reasons why it's done. It's different from other open source projects, but /. has overlooked that fact)
No, but you do need to be completely ignorant of the rules by which GCC operates.
Feh. I submitted this story the day it happened, with a better writeup, too. I forgot my name's in the auto-rejector. Anyhow...
This was discussed on the GCC lists, and rejected. The obsoletion procedure (announce deprecation in release X, remove support in X+1 if nobody steps up to maintain it) would be completely inappropriate for this case. The SCO platform is still actively maintained. It would also turn the obsoletion rule into a political one, instead of a purely technical one like it is now.
Okay, fine, you may say, then don't use the obsoletion rules, use new ones. But the obsoletion rules are, at present, the one ones which permit the GCC maintainers to drop support for platforms wholesale. It's the FSF who makes the political decisions, not the maintainers.
That's a good troll, and it would be funny, except that every time someone tries these jokes on
If you care that much, provide the support in GCC. Either write the code yourself, or convince/hire someone else to do it for you. They've gone supported for a long time now, which means that nobody cares enough.
If you care, but not quite enough, then use an older compiler.
Ha, ha. You conveniently ommitted the "Windows NT 3.x" part of the obsoletion name.
Because maintaining it was a pain in the ass, and blocked the fixing of other bugs.
If you must compile older code, rather then a newer version of that code, then use an older compiler.
A horse is a horse, of course, of course.
A Jedi horse, he uses the Force.
His favorite code to use is Morse.
He's the famous Mister Ed!
From goats.com, one of the funniest comic strips on the web. (Hint: read the "kittens = poptarts" series from their archives.)
Isn't that carrying alliteration a little too far?
(Hint: say it aloud.)
Okay, I'm sorry. I've just always liked that one.
No, I don't live in a small podunk town. Sorry to disappoint you. But neither do I live in California, and that's where your misunderstanding lies.
Your analogy shoots yourself in the foot. If I go to the Castro district and 11 out of 12 are gay, you are correct, I can't extrapolate that to the rest of the world.
Likewise, if I go to the middle of Silicon Valley and the judges there know about Linux, I can't extrapolate that to the rest of the world either. Or even the rest of the country. People at large are not as tech-savvy as people in Silicon Valley. That judge is the exception, not the rule.
If you don't agree, if you feel Silicon Valley is the American norm and everywhere else is podunk, well, your opinion is your opinion. I disagree. And I think we can leave it at that. If you'd like to make more childish comments about professional lawyers "not knowing what the fuck is going on" because they happen to not live in California, go right ahead.
It's not sterotypes. It's statistics. 11 out of the 12 people I know in law offices have never heard of Linux. Three of them say that their colleagues (they didn't say how many, unfortunately) at other law offices have never heard of Linux either.
From that, I extrapolate that -- again, read this slowly, since you seem to have trouble with the concept -- it's a safe bet that the average person in a law office does not currently know of Linux. So, we need to get the word out. :-)
Nothing about eliteness, or snobbery, or sterotypes. Sorry if that offends you.