Issues that NAT causes? Like shielding n00bs from the wilds of the internet?
NAT is a blessing. It allows people to access the net without being exposed to it.
Someone should write some software that can be put on a router that would offer the same protection without also causing all the problems that come with NAT. It would be like this large barrier that burns up any unauthorized data that tries to get by.
That would be really stupid, when all you need is filtering in the destination IP stack
which (a) knows which addresses want this filtering and which don't, and
(b) has processing power to spare.
I think they call this a "personal firewall", and I think I have heard that several popular OSes include one.
I am actually better off with a old copy of xv that hasn't been maintained in years.
s/years/fifteen years/.
There are user-created patches (google for them) but the official xv 3.10a was released on the last day of 1994.
And it still kicks ass; I've been using it heavily today.
Do what you think is right.
You seem to have a decent work ethic, so don't slack off just because the
others do.
But don't isolate yourself. *Some* of that chatter is legitimate,
and you'll be less useful and have less fun at work if you don't know your
coworkers. Sometimes you can steer the conversation over to something work-related
once in a while (even complete slackers usually enjoy discussing things like the
possible usefulness of the product, or old war stories).
Make it clear, preferably in a friendly and non-obvious way,
that work has priority in your mind. If people come and bother you while
you're working, excuse yourself after a while.
If you come to someone for help and that guy is e.g. in a deep discussion about
soccer, don't wait around. Politely interrupt him.
I think it would be unwise to complain to management. They can figure it out for themselves, if they care to.
NB this advice is based on my experience with mostly mild slackness, and in.se
(I have been told work politics differ a lot between countries).
1) People have life outside work. And noone is going to just hang on friends/family with "can't talk, i am at work". That would be way too porr social skills.
That attitude seems common (here in.se) nowadays, but it certainly wasn't when I grew up (i.e. before the cell phone).
You did *not* try to reach people at work, unless a family member had ended up in hospital or the house was on fire. The workplace was another world.
And I think that's the way it should work.
I get pissed off if I'm helping a coworker with something, and a call
from his/her girl/boyfriend suddenly gets priority.
2) Making friends in workplace is a must, if only because you need to cooperate with people and workign with friends is easier than working with bunch of robots.
I agree on this one.
Not necessarily to become *friends*, but to understand how they're thinking.
And for fun, of course. Noone said you can't have fun at work.
There's no reason to even do this unless you're aligning tabs with other characters, which you should never do precisely because tabs widths vary.
No they don't. The standard TAB width is 8. If the team doesn't agree on that, the only sane choice is to ban TABs (which many do).
I have seen some people argue (like you) that sticking exclusively to TABs for indentation and using them for nothing else
means a guy with 8-TABs can cooperate with 3, 4 and 5-TAB people, but I suspect that it would break down in practice.
It would also be hell for anyone who uses standard 8-TABs but finds an 8-space indentation intolerably deep -- i.e. for most people.
Use tabs only at the beginning of a line for indentation, and not to create "columns" in variable declarations, hash maps, etc. (Personally, I can't stand that layout style anyway.)
Agreed, at least for variable declarations.
That this style sucks gets very obvious when you have to change/add a type or a variable name, and are forced
to realign a whole list of unrelated things around it.
(Yes, you have to reindent when you add a nesting level too, but that's much more rare
and there's usually no way around it.)
On all machines I've coded for the right-shift on signed numbers have always been arithmetic. While not being a standard it is recommended C, and applies to atleast x86 and PowerPC.
Recommended by *you*, you mean.
*I* recommend staying away from undefined, obscure arithmetics in C as much as possible.
You'll get into enough trouble as it is, without having to memorize not only the language, but also
the workings of your particular set of target CPUs and compilers.
There is a school of thought among programmers who consider themselves hotshots that if you are not a hotshot you have no business touching their code. The problem with this attitude is that it has little to do with the real world, where people change jobs and programmers inherit someone else's code.
I agree. But then there's the other extreme, where you're supposed to write code
for the least common denominator. Like not use any "advanced" language features, in case
a novice will stumble across the code and not immediately understand it.
What's really annoying is when they put comments that don't elucidate the code or their intent; they're just snide little messages from one know-it-all to another. They're too embarrassed to actually explain the code because that implies a level of insecurity they would rather not admit to. So instead they say things like: /* yeah, I don't like this either */
or
# hack, to be fixed later
Wooooo, really helpful comments there. I've seen this sort of thing countless times in my career and most others I know have as well.
If that's not something which "implies a level of insecurity", then what is?
It's much better than keeping silent and hoping noone notices the fart smell -- lots of people do that.
I admit that it's sometimes not enough, and when it isn't the reader has a right to be pissed off...
but IME usually the ugliness is so obvious that nothing more needs to be said.
I really love emacs, but there are four things that I really would like to have and that you can find in most IDEs: proper support for out of source builds, on-line help for functions/classes, contest based highlighting of #ifdef blocks and something like Intellisense (there is something available in emacs,but is still in development, didn't try it for a while though).
out-of-source builds (having the sources in one directory, building to another)
is not the responsibility of your text editor; it's the Makefile's job.
I'm surprised that you think Emacs somehow prevents it from working.
Online help? I prefer to read the sources, where the help surely originates.
If you're talking about library help, you can read it as info or man pages.
I admit that the tags feature (of emacs and vi) could work better for languages like C++ --
right now you can search for a find() method and get a dozens of different hits.
Unfortunately that requires the editor to understand the language's type system.
What about M-x cpp-highlight-buffer? Seems to be exactly what you ask for.
On the other hand, if you need it regularly, I feel sorry for you.
Ifdefs are a maintenance nightmare no matter what editor you use.
Intellisense? I have never used it, but I'm sure M-x dabbrev-expand (an ancient Emacs feature, also available in Vim under a different moniker) is superior.
Works everywhere, in any language -- I rely on it for all my writing.
Either that or it's pretending it's a nautilus. Octopi are relatives (same class, Cephalopoda) of nautiluses, which are the only extant cephalopods with an external shell...that's secreted by the animal and not made of coconut.
I think GP's point was that the Hermit Crab *does* find an unused shell of
suitable shape and size and carry it around, so what's new?
I don't quite understand why the octopus story is a big deal... if its
behavior is based on instinct rather than rational thinking, it only
proves octopi are not dumber than craps, and we knew that already.
I think the newest generations of free software developers take free software for granted.
They do not know how things went before GNU and Linux were there, when to have an usable development environment you had to pay for an operating system (more expensive if it was a developer-oriented version), a windowing system, a file manager, an office application, a web browser, an email client, a compiler, a debugger, a zip program, a picture viewer, access to the official developer's documentation, and a full set of "Undocumented %s" books. Not to mention any library you might want to use.
I see your point, but it wasn't *exactly* like that.
At least on Unix, there were always plenty of people who shared code for free. Things like X11, Perl, TeX,
all the stuff posted to comp.sources.unix...
Stallman just put it in writing (in a way many but not everybody agreed with) and supplied a C compiler to
those unfortunates who didn't have one.
Personally I don't care if Linux is ever employed by the "average person". I'm not one of those people and the work I do requires people who know what's going on.
I *do* care. But the average person will have to learn what's going on.
The other way lies Windows clones, Gnome, and insanity; they might as well stick with Windows.
Gnome: I despise it.
I've watched it "work" on big multi-user servers (with dozens of users
with Gnome sessions via VNC).
It throws up dozens of random processes per user, all undocumented, which (according to Google searches,
since there is no documentation)
do things like serve sounds which do not exist, poll for updates which never come,
run 100% CPU screensavers which noone watches, crash randomly, lock up at 100% CPU, and leak memory.
Every time I run top(1) the gnome-terminal processes are, well, at the top.
Sometimes? Unless you' only want to mess with individual bits and memory locations (for which C is really the only choice),
Funny, I was messing with individual bits in C++ earlier today.
C is almost as verbose as Java, and C++ is equally verbose.
So what's the equally verbose C version of this? (C++, because I don't know modern Java)
int foo(std::map<std::string, int>& bar) { return ++bar["baz"]; }
Sorry, but you don't make sense. I agree that C, Java and C++ code is more verbose than
the Python or Perl counterparts, but lumping them together is ridiculous, and FUD.
Maybe some companies think of testing that way...
Real, useful testing requires imagination, sadistic tendencies, good technical knowledge,
and I guarantee what you see is far from predictable.
A good tester is often more respected in a team than the good programmer.
#define f(x) (x = x / 3.1459) ... #define f(x) ( x = g(x); x = x / 3.1459) ... if (object.type() == "circle") f(object.radius); ...
Guess what that if statement will look like to the compiler? Brackets are very much better to use and make code clearer to both the programmer and the compiler for what is going on.
I use if() {...} brackets because my readers expect it. That's enough reason.
We have all kinds of crappy bracket positioning and indentation styles, but the brackets are always there
(except in some special pattern cases).
As for your example:
Noone in his sane mind does multi-statement macros like that.
Wrap them in a do {... } while(0) and the problem goes away.
This is 2009. Inline functions have existed in C++ for decades, and in C since 1999.
You don't have to use macros a lot these days.
And if you do, you name them FOO rather than foo, so people understand that something
funny is going on.
Your macros are broken anyway... side-effects of evaluating (x)... lots of fun.
(Yes, I know those macros were probably just quick examples.)
To be fair,.deb packages are even quicker and more convenient than.msi installers. You just need admin privileges to run them - hardly more of a speedbump than a UAC prompt if you're running a distro with gksudo/kdesu.
I have no idea what gksudo/kdesu is... but who is stupid enough to download Debian packages from random places?
If I see software that seems nice, but it's not already in the Debian archive (or at least in unstable),
I immediately wonder what's wrong with it.
But I agree -- if Linux users start to act like Windows users, we are truly in deep shit.
Operating system these days are not so much about the kernel, but about what abstractions the kernel offers. The Unix abstraction, i.e. everything is a file, is a good one, and if we think about it in modern terms, it's nothing more than object orientation: a specific class behind each file does specific things with the data it accepts. The same data can be sent to the same file, but the executed code would be different.
So why not make everything object oriented? forget processes and files, think objects. What files lack is retrospection, i.e. what messages accept and what format is the data they accept. That's the next logical progression from processes and files. With the appropriate object-oriented facilities, an O/S would become much more programmable and flexible.
No, it would be the COM object insanity all over again.
The point with the Unix files (input and output streams of characters really) is
that they are untyped.
What you suggest *does* exist, though: ioctl(2). When was the last time you used those?
Right: they're a kludge for special situations, not a new wonderful general idiom.
Everybody seems to dislike ESR, but do yourself a favor and go read "The Art of Unix Programming".
It discusses precisely these things.
"... you're american (yours is the only country where anyone would take you seriously with rubbish like that, due to a cultural meme that has no base in reality)..."
Ah, so rather than making knee-jerk judgments about operating systems, we are going to make knee-jerk judgments about a whole "culture", rather than just (more properly) assuming his attitude is the result of ignorance, and not part of our "culture"? You just committed exactly the same kind of mistake he did, but you are insulting a whole culture, rather than just some licensing scheme. [---] accusing an entire nation [---]
Settle down, Beavis... he didn't do any of that.
He just claims there *are* people in the US -- and nowhere else -- who swallow "communist scare" arguments,
not that the average american does.
FWIW, I think he's wrong about the "nowhere else" part.
There are people who buy that argument everywhere.
One seems (note I said seems, not implying at all that it's unavoidable) to be that the more human readable and dummy proof the more overhead you pay when you design/implement a programming language. You might find the C/C++ crowd commonly accuse the Java or Ruby crowd of this overhead.
I'm in the C++ crowd, and I've never seen Ruby accused of anything.
Ruby -- and Python -- are perhaps ignored too often, but the only thing that people really dislike is
the dynamic type checking. I think it's generally accepted today that most programs don't need maximum speed.
Indeed, Java has a garbage collector designed to protect you from memory leaks.
I have to mention this every time praises Java's GC as protection from memory leaks:
I program professionally in C++ all days, and I never have problems with memory leaks.
The language handles that for me (unless I do really stupid things on purpose).
Whatever GC does for everyday programming, it's *not* protection against memory leaks.
This progression toward using English words and syntax to program a computer is less about dumbing down code and more about encouraging people to document their code.
Where do you see such a progression?
A proprietary language noone would have heard of unless ZDNet had decided to make fun of it?
All new languages I've seen try to go for clarity, but
*never* by trying to be like a natural language.
Ideally, a programmer should document each section of code by writing a block of comments explaining (1) why the code is used and (2) how the code works -- in plain English.
That's terrible advice, IMO. What's a "section of code" anyway? We started doing structured programming
in the 1960s -- so we can document functions or classes, not "pages of assembly code" or "punchcards" or whatever.
The programmer must still write comments explaining "why the code is used".
That's the only fragment of your posting I agree with.
However, I think that's usually the user documentation, or maybe an architecture document (aka "README file")
written by the programmer and stored with the source code.
Isn't the best approach to develop fast, identify the bottlenecks and then rewrite those parts in a faster language, like Python C modules?
You can't "re-code" bottlenecks at the architectural level, even if your language allows a cost-effective way to write and call native written modules. And that's the danger of "develop fast, identify and fix later".
I always suspected that the *real* lesson is that you normally find no such bottlenecks.
That the "oh, you can always rewrite the bottlenecks in C" mantra is like when you tell
a small child "if the monster under the bed tries to eat you, daddy will come and suck it
into the vacuum cleaner".
Then he must not realize that SVN can do everything he's wanting to do.
My thought exactly. If he doesn't like that answer, it's his fault for not
mentioning why it wouldn't work for him.
I use CVS for exactly what he describes. I don't do binary files that way,
but then again you cannot do anything like this reliably with files which cannot
be merged -- edit them in two places and you lose.
I'm not [a graphics professional] and I have somewhat the same reaction. I've gotten ahold of one or more GIMP docs and tried to step through them to learn how to use it. I generally found that, although I could easily learn to tell it to do all sorts of things to an image, what it did was rarely what I expected, and couldn't be explained by reading the docs that I had. So I was able to use it to do all sort of damage to images, but I could rarely get it to make the changes that I wanted to make.
Some things about the GIMP annoy me -- like it insists on UTF-8 encode file names even though
it's in my normal 8-bit locale.
But for the most part it just works as I want it to.
I've never read any manual -- you learn by experimenting a bit. Most things are pretty
intuitive and useful.
Slashdot Mirror
Have you reviewed them all, or what? Care to give an example?
That would be really stupid, when all you need is filtering in the destination IP stack which (a) knows which addresses want this filtering and which don't, and (b) has processing power to spare. I think they call this a "personal firewall", and I think I have heard that several popular OSes include one.
s/years/fifteen years/. There are user-created patches (google for them) but the official xv 3.10a was released on the last day of 1994. And it still kicks ass; I've been using it heavily today.
Do what you think is right. You seem to have a decent work ethic, so don't slack off just because the others do. But don't isolate yourself. *Some* of that chatter is legitimate, and you'll be less useful and have less fun at work if you don't know your coworkers. Sometimes you can steer the conversation over to something work-related once in a while (even complete slackers usually enjoy discussing things like the possible usefulness of the product, or old war stories).
Make it clear, preferably in a friendly and non-obvious way, that work has priority in your mind. If people come and bother you while you're working, excuse yourself after a while. If you come to someone for help and that guy is e.g. in a deep discussion about soccer, don't wait around. Politely interrupt him.
I think it would be unwise to complain to management. They can figure it out for themselves, if they care to.
NB this advice is based on my experience with mostly mild slackness, and in .se
(I have been told work politics differ a lot between countries).
That attitude seems common (here in .se) nowadays, but it certainly wasn't when I grew up (i.e. before the cell phone).
You did *not* try to reach people at work, unless a family member had ended up in hospital or the house was on fire. The workplace was another world.
And I think that's the way it should work. I get pissed off if I'm helping a coworker with something, and a call from his/her girl/boyfriend suddenly gets priority.
I agree on this one. Not necessarily to become *friends*, but to understand how they're thinking. And for fun, of course. Noone said you can't have fun at work.
No they don't. The standard TAB width is 8. If the team doesn't agree on that, the only sane choice is to ban TABs (which many do). I have seen some people argue (like you) that sticking exclusively to TABs for indentation and using them for nothing else means a guy with 8-TABs can cooperate with 3, 4 and 5-TAB people, but I suspect that it would break down in practice. It would also be hell for anyone who uses standard 8-TABs but finds an 8-space indentation intolerably deep -- i.e. for most people.
Agreed, at least for variable declarations. That this style sucks gets very obvious when you have to change/add a type or a variable name, and are forced to realign a whole list of unrelated things around it. (Yes, you have to reindent when you add a nesting level too, but that's much more rare and there's usually no way around it.)
Recommended by *you*, you mean. *I* recommend staying away from undefined, obscure arithmetics in C as much as possible. You'll get into enough trouble as it is, without having to memorize not only the language, but also the workings of your particular set of target CPUs and compilers.
I agree. But then there's the other extreme, where you're supposed to write code for the least common denominator. Like not use any "advanced" language features, in case a novice will stumble across the code and not immediately understand it.
If that's not something which "implies a level of insecurity", then what is? It's much better than keeping silent and hoping noone notices the fart smell -- lots of people do that. I admit that it's sometimes not enough, and when it isn't the reader has a right to be pissed off ...
but IME usually the ugliness is so obvious that nothing more needs to be said.
Why web-based? In order to get a horrible user interface and information lock-in? (There are pros too, but you didn't mention any.)
I think GP's point was that the Hermit Crab *does* find an unused shell of suitable shape and size and carry it around, so what's new?
I don't quite understand why the octopus story is a big deal ... if its
behavior is based on instinct rather than rational thinking, it only
proves octopi are not dumber than craps, and we knew that already.
I see your point, but it wasn't *exactly* like that. At least on Unix, there were always plenty of people who shared code for free. Things like X11, Perl, TeX, all the stuff posted to comp.sources.unix ...
Stallman just put it in writing (in a way many but not everybody agreed with) and supplied a C compiler to
those unfortunates who didn't have one.
I *do* care. But the average person will have to learn what's going on. The other way lies Windows clones, Gnome, and insanity; they might as well stick with Windows.
Gnome: I despise it. I've watched it "work" on big multi-user servers (with dozens of users with Gnome sessions via VNC). It throws up dozens of random processes per user, all undocumented, which (according to Google searches, since there is no documentation) do things like serve sounds which do not exist, poll for updates which never come, run 100% CPU screensavers which noone watches, crash randomly, lock up at 100% CPU, and leak memory. Every time I run top(1) the gnome-terminal processes are, well, at the top.
Funny, I was messing with individual bits in C++ earlier today.
So what's the equally verbose C version of this? (C++, because I don't know modern Java)
Sorry, but you don't make sense. I agree that C, Java and C++ code is more verbose than the Python or Perl counterparts, but lumping them together is ridiculous, and FUD.
Maybe some companies think of testing that way ...
Real, useful testing requires imagination, sadistic tendencies, good technical knowledge,
and I guarantee what you see is far from predictable.
A good tester is often more respected in a team than the good programmer.
I use if() {...} brackets because my readers expect it. That's enough reason. We have all kinds of crappy bracket positioning and indentation styles, but the brackets are always there (except in some special pattern cases). As for your example:
Or stay and become that lousy and obviously unhappy manager who used to be a good tech.
I have no idea what gksudo/kdesu is ... but who is stupid enough to download Debian packages from random places?
If I see software that seems nice, but it's not already in the Debian archive (or at least in unstable),
I immediately wonder what's wrong with it.
But I agree -- if Linux users start to act like Windows users, we are truly in deep shit.
No, it would be the COM object insanity all over again. The point with the Unix files (input and output streams of characters really) is that they are untyped. What you suggest *does* exist, though: ioctl(2). When was the last time you used those? Right: they're a kludge for special situations, not a new wonderful general idiom.
Everybody seems to dislike ESR, but do yourself a favor and go read "The Art of Unix Programming". It discusses precisely these things.
Settle down, Beavis ... he didn't do any of that.
He just claims there *are* people in the US -- and nowhere else -- who swallow "communist scare" arguments,
not that the average american does.
FWIW, I think he's wrong about the "nowhere else" part. There are people who buy that argument everywhere.
I'm in the C++ crowd, and I've never seen Ruby accused of anything. Ruby -- and Python -- are perhaps ignored too often, but the only thing that people really dislike is the dynamic type checking. I think it's generally accepted today that most programs don't need maximum speed.
I have to mention this every time praises Java's GC as protection from memory leaks: I program professionally in C++ all days, and I never have problems with memory leaks. The language handles that for me (unless I do really stupid things on purpose). Whatever GC does for everyday programming, it's *not* protection against memory leaks.
Where do you see such a progression? A proprietary language noone would have heard of unless ZDNet had decided to make fun of it? All new languages I've seen try to go for clarity, but *never* by trying to be like a natural language.
That's terrible advice, IMO. What's a "section of code" anyway? We started doing structured programming in the 1960s -- so we can document functions or classes, not "pages of assembly code" or "punchcards" or whatever.
That's the only fragment of your posting I agree with. However, I think that's usually the user documentation, or maybe an architecture document (aka "README file") written by the programmer and stored with the source code.
I always suspected that the *real* lesson is that you normally find no such bottlenecks. That the "oh, you can always rewrite the bottlenecks in C" mantra is like when you tell a small child "if the monster under the bed tries to eat you, daddy will come and suck it into the vacuum cleaner".
My thought exactly. If he doesn't like that answer, it's his fault for not mentioning why it wouldn't work for him.
I use CVS for exactly what he describes. I don't do binary files that way, but then again you cannot do anything like this reliably with files which cannot be merged -- edit them in two places and you lose.
Some things about the GIMP annoy me -- like it insists on UTF-8 encode file names even though it's in my normal 8-bit locale. But for the most part it just works as I want it to. I've never read any manual -- you learn by experimenting a bit. Most things are pretty intuitive and useful.