I'm running a 2.6 kernel(with sid) on a PII 350, with 384, but I wouldn't try with less, unless it was doing almost nothing... You need more room than that...
Surely you're joking?
I routinely use a Pentium Pro 200 MHz with 64 MB RAM
for programming, image manipulation etc.
Works fine almost all the time -- in maybe half the raw CPU speed of
your machine, and a sixth of your RAM.
The first problem you hit on a slow machine is the web browser.
Both Opera and FireFox would be intolerably slow on either of our machines, I think.
And there won't be, until manufacturers start writing (hopefully open source) drivers for Linux.
And they won't do that if the kernel API keeps changing every five minutes.
In the case where the driver is free software: why not, exactly?
Write a free driver, submit it to Linus and/or place it on your home page,
and someone will do the (most likely trivial)
modifications when needed.
I find it hard to believe that significant changes in a certain driver area
(say, NICs) happen "every five minutes" or with "every single kernel release".
Standardization of software development tools and languages has to do with optimizing the process at a higher level than most developers are used to.
The point here is to optimize the way a whole company (or at least a whole division) produces software:
Standardized support tools (build tools, version control, etc) mean that there will be things like shared project templates and a higher average level of expertise with the tools being used (if everybody uses the same tools, there will be more experts with those tools around).
Standardized languages mean that in-house developed libraries and frameworks are feasible and can be reused all across the company in many of the projects being developed.
Hm, didn't we try that "in-house code reuse" thing
back in 1992?
And besides, it's not like we're talking about using hundreds of languages in a company
unless someone stops the madness --
for any given task, there tends to be two or three reasonable candidates.
Standardization in tools and languages also increases predictability of results - everybody, including managers, gains a better grasp on how long it takes to do something since they have a lot more experience using that set of tools and languages.
That's an argument against using a new set of tools and techniques for every new project,
but who in his right mind would do that anyway?
You pick something which is suited to the task, something people know about,
and something which can be useful later.
Standardization also means that it's a lot easier to find and train replacements for those that leave or (even more important if you're a developer) those that progress in their career to new tasks and responsibilities and don't want to be stuck "maintaining the software I did 4 years ago".
Not if you standardize on something exotic, obsolete, expensive which people outside
the corporation never use -- like Ada, or various "visual programming" languages.
If standardization meant
"use whatever bright people tend to use for these kinds of jobs"
then I could agree with you, and happily keep doing plain old Unix programming using C,
C++, Python and shell scripting until something distinctly better comes around
in twenty years or so...
But in my experience, corporations rarely make sane top-level technical decisions.
They read glossy magazines and get visits from sales-people instead...
Linux doesn't work well in the business world for ordinary users. Trust me. It doesn't. They need stuff that is windows only.
At some point these people will have to do something about vendor lock-in...
Anyway, the grandparent wasn't suggesting that everybody should move to Linux.
He suggested that if you have a sensible way of installing and updating installed
software (using Linux package managers as an example) one of the often cited
reasons for using crappy web apps goes away.
Then there's the third option: having the admins keep software installed in one
copy (or one per OS and architecture) on a central file server, on a file system which everyone mounts.
This has worked nicely since Sun invented NFS twenty years ago, and I cannot see
why so many people refuse to use it today.
Or does Windows prevent this too?
I work with a guy who insists on using Visual Studio, as nearly as I can tell, because he's unaware that there is a multi-tab text editor outside of VS. So, everytime I have to take over a project from him, I have to go figure extract what files are being build, and then port it into the production system, every other developer on the project uses. Because this is such a hassle, the guy will do updates and commits on an interval measured in months, where as every other developer does them on intervals measured in hours. So along with everything else we have to deal with, when he commits his code, he generally will blow away months of someone elses work because he can't be bothered with learning how resolve conflicts, and it'll never integrate cleanly. We'll spend a week just trying to undo all the damage he'd done. All because he can't be bothered to use the same toolchain everyone else on the team does.
It's not the toolchain. He's an idiot (and you are too, for letting him do this.)
You can use Visual Studio as a text editor and still interface the things you produce
with what others produce (unless there are some DOS line ending or TAB quirks in VS).
You cannot, of course, set up a VS build system, if all of the people you work with
use Gnu Makefiles!
Management invariably tries to standardize the wrong tools because they have no idea how software development works. They think in terms of the IDE as "the tool set" rather than the MAKE or ANT build systems, compiler toolchain, version control, and other behind the scene tools.
If you want the standardization to go well, make sure the build tools are standardized. Once anyone can build the project (IDE or no), it won't matter what the "standard" IDE is. (Unless it's Rational Application Developer. That's just a piece of shit right there. Universally agreed upon.)
Rational sell IDEs now? Uh-oh... *curls up in fetal position*
Developers will still download their own editor or IDE tools to make themselves happy without disturbing the greater whole.
You're right, of course.
With Emacs and Vim, you can have editor wars during coffee breaks, then
go back to your editors of choice and work on the same code...
But all this assumes that someone makes sure no moron ties
the build system tightly into a specific IDE.
And IDEs love to offer plenty of opportunities for this,
and people who are in love with their IDE think this is the way it should be.
Also, why are people so hesitant to use multiple levels of DNS domains? Couldn't that server also be named mark-pfs-01.sjc.whatever.com? That way, everyone in SJC knows it just as "marketing production file server 01". Only people off-site need to realize that it's in SJC.
I've wondered that myself. Probably because few people understand the usefulness of name spaces,
as a general concept.
Or that their bosses think that if there's a dot in the name, it is a FQDN and has to end in.com...
Also, as a general comment:
if the hostname is harder to remember than the IP address, you are doing something wrong.
As an end-user, I'd appreciate if the sysadmin didn't use the hostname as a general
asset management database. The FQDN is a key into such a database, not a record.
I'm not a professional magazine photographer (as in, photographer of magazines), but these tips might help. Whenever I photograph a document or painting, I just use my plain ol' digital camera.
A few things: [---]
Good advice, but it's worth pointing out that you can be much sloppier
than that and get away with acceptable results.
I typically move two 100w bulb lamps to my desk, stand up with the book on the table,
hold the book open with one hand, and take a picture with my camera in the other hand.
Flip pages, and take another picture, and so on.
This is surprisingly fast (20 pages per minute or so) and works well
for text and black-and-white illustrations, if all you want is to be able to
read the text afterwards.
Anyone who says "expressive and concise" is more important than "debug and maintain" needs to be run out of the industry on a rail, then tarred, feathered, and finally shot.
First, noone said it was more important.
Secondly, expressiveness and conciseness are supposed to help during maintenance.
I'd rather debug a complex Perl regex than the equivalent hand-written parser.
BTW, I use C++ daily, but I've never found a use for multiple inheritance.
It's the spare tire in the trunk of my C++ car, and that was what it was designed to be.
Ditch your diagrams. They're far too often used to:
1) As a thing to show boss that you're working.
2) Unnecessary cruft which no one uses.
And/or 3) something everyone except the boss knows is out-of-date and dangerous to refer to for anything important.
It's strange that the question explicitly asked for diagrams.
What if this particular system is better described in plain text --
should there still be diagrams instead?
Apart from that I only have three pieces of advice:
Any documentation which isn't under revision control together with the software
is doomed to fail.
That means among other things it has to be inside the source code, or in separate plain text files
(so your changes can be merged with my changes, and so they can be reviewed alongside the
source code).
Spend a day or two with doxygen. Make sure you enable its graph-rendering
capabilities, and then play with different settings.
You can get quite a lot of overview and insight from its output, and it supports plain C.
Doxygen cannot capture the architectural decisions and rules.
Those that change rarely should, I think, be written down in plain text by someone who knows
a lot about the system and who can write readable technical documentation.
But for the volatile details, I'd rather trust the source code (and the views of the source code
which doxygen, emacs, various IDEs... can offer).
And this bit of legislation, whether we here in the States realise it or not, has much broader implications than just the privacy of Swedes being impeded; as I understand the article, any communications that hit Sweden are subject to monitoring; and as the article doesn't cite whether or not this requires the Originator or Terminator of a given communication be physically present in Sweden, this could include US-based items that pass through a network element of some sort that IS Swedish.
According to earlier news, they would tap everything at the border, so
if you had e.g. a.us--.us route or an.se--.se route which crossed the border,
your packets would be covered.
I'm a pretty tech-y person, and I haven't touched Usenet since 2001 or so. I don't miss it. Might as well criticize Verizon for not keeping their Gopher site in order, or offering Telnet access to email... let's move on already.
But some of us don't understand why we need to "move on" from a superior technology.
NNTP plus a good news reader still beats Slashdot and all other web forums
in terms of usability/user-friendliness.
A basic problem with open source is that once you get beyond the top 50 or so projects, the quality is usually crap. Look at the source from a few random projects on SourceForge. There aren't that many real "community" projects, where multiple programmers are working on the same code. The long tail isn't very good.
You have a point, but s/the top 50/the top 1000 or so/.
You have to count various C libraries, and things like the Perl modules at CPAN.
Many of them are in wide use, and should be trustworthy.
Also, I'm not so sure that community projects are
generally better than single-person projects -- if you don't count crap projects
which only the author can love.
I myself still tend to expect anything but the most basic open source software projects to be only 50% developed (or even abandoned completely) or to have a poor feature set compared to commercial alternatives [...]
That depends very much on where you're looking.
I'm sitting here with a traditional Unix installation (Debian Linux, with none
of the Windows rip-off GUI thingies like Gnome and KDE), and all of it is free
and excellent.
In this area, it's the commercial alternatives that suck. If there are any.
I just spent time working on a two-year project where some cockfag consultants said they could spend 10 months creating the various UML diagrams, convert the diagrams to code in 1.5 months, test for two weeks, and deliver to the client.
So what actually happened?
You know, you didn't have to answer that question.
Don't be an idiot. Python is used in the industry just fine--look at EVE online. The fact that you're fixated on type safety is your limitation, not that of the language. Types are an INVENTION, not an inherent item of a programming language.
Yeah.
And still, there are times and places for static typing.
I am not a novice Python programmer,
but when my Python programs grow large enough, I find myself longing for
a C++ compiler (with the warning level cranked up to the max of course,
with C-style casts forbidden, and no unnecessary inheritance).
Unit tests help a bit, but they never seem to be enough for me.
On the other hand,
when my Python programs are fairly small (but non-trivial)
Python's type system is great. And most of the things I do are fairly small...
Also doing things in a scripting language and having C do the heavy lifting... sounds like Tcl, Lua, JavaScript. Python offers nothing new there.
Of those languages, only Tcl has a longer history (as a well-known general-purpose language, at least) than Python. And lots of people find Tcl antiquated, primitive
and ugly.
What Python offers is a free, high-level scripting language with
a simple and elegant syntax, a good standard library,
and strong, dynamic typing.
It happens to be easy to write Python wrappers for C code too --
about as easy as Tcl, I'd say -- but it's hardly its main strength.
The problem is that to do a full map of this would take far more processor time then any group would be willing to give so programs that do this need to take clever little short cuts. This cause the user that the parent is talking about.
Do I understand it correctly?
Well, not exactly.
Some of those short cuts can be made in a clever way
(as opposed to a "clever" way) so that an analysis can take less than a decade
and still be useful.
At least that's roughly what a Polyspace salesman once told me.
Closed Source Developer: I will try to do my best job as I possibly can so I can keep my job and make money because that is what I value.
Open Source Developer: I will try to do my best job as I possibly can so I can help the comunity and feel better about myself/get myself noticed in the comunity/Something cool to put on my resume... because that is what I value.
I think you've missed something.
Many (most?) good programmers have a drive to write elegant and correct code.
It doesn't matter who pays them, or if they meet their peers by the corporate coffee machine
or on a mailing list.
What's specific to corporate code ("open source" or propietary) is at least one thing:
a manager can come up to you and say "you will code feature Foo and be done on date Bar",
and the programmer will kludge it, even if he knows Foo cannot be done in a robust way,
and the best option would be not to try at all.
Where do you find good sci-fi that's also a good book?
Kurt Vonnegut.
Vonnegut was special because he had cred inside SF fandom,
and he had cred as a "serious" author.
I like him in principle, but secretly find him a bit tedious.
But come on!
Unless you define "a good book" as
"a book which an irrational SF hater would want to read",
the question is meaningless.
A bad story can never be a good SF story.
We decide what is "good" and what isn't --
and we can happily ignore journalists and academics.
Debian makes tons of needless changes to lots of packages. Many times I have looked into bugs only to learn they were introduced by Debian. (I use Kubuntu.) Probably more than half the bugs I've searched for information about were Debian's fault. They just refuse to leave things alone.
It's like not-invented-here syndrome, but instead of building new software, they just make all sorts of random changes to existing software so they can feel like its their own.
And you are saying Debian are special in this way?
That RedHat, Novell (or whatever the commercial ones are called; I have lost track) don't?
That the *BSDs don't?
That the commercial Unices don't?
As far as I know, all of them apply their own patches (or others' patches)
when they feel it's useful. The question is if you trust them to do it decently well,
and in a way which suits you.
For example, I agree with Debian's policy on writing man pages when the upstream didn't bother
to do it.
In the article, it kind of joked about getting used to a 'text email' client. Why is this a joke?
AFAICS, no joke was implied.
The poster truly believes somehow that a text mail client is more efficient over dialup.
That is fiction, of course.
Downloading mail POP3-style works better over a slow line than
IMAP-style mailbox access, but both GUI and text mail clients do both.
Also, it is easy to make even Outlook send just the text.
And you cannot prevent even the simplest reader from POPping HTML crap and
Powerpoint attachments.
Web mail services like Gmail and whatever they are called are GUI-only
and probably painful over slow lines, but you do not have to run Mutt or/bin/mail
to avoid them.
Not too bad, actually.
You get a feel for the author's frame of mind when (s)he wrote that.
I am guessing:
reasonably clever, and aware that he writes for an audience
-- but with a deadline coming up, and more urgent problems to deal with.
Slashdot Mirror
Surely you're joking? I routinely use a Pentium Pro 200 MHz with 64 MB RAM for programming, image manipulation etc. Works fine almost all the time -- in maybe half the raw CPU speed of your machine, and a sixth of your RAM.
The first problem you hit on a slow machine is the web browser. Both Opera and FireFox would be intolerably slow on either of our machines, I think.
In the case where the driver is free software: why not, exactly? Write a free driver, submit it to Linus and/or place it on your home page, and someone will do the (most likely trivial) modifications when needed.
I find it hard to believe that significant changes in a certain driver area (say, NICs) happen "every five minutes" or with "every single kernel release".
Hm, didn't we try that "in-house code reuse" thing back in 1992? And besides, it's not like we're talking about using hundreds of languages in a company unless someone stops the madness -- for any given task, there tends to be two or three reasonable candidates.
That's an argument against using a new set of tools and techniques for every new project, but who in his right mind would do that anyway? You pick something which is suited to the task, something people know about, and something which can be useful later.
Not if you standardize on something exotic, obsolete, expensive which people outside the corporation never use -- like Ada, or various "visual programming" languages.
If standardization meant "use whatever bright people tend to use for these kinds of jobs" then I could agree with you, and happily keep doing plain old Unix programming using C, C++, Python and shell scripting until something distinctly better comes around in twenty years or so ...
But in my experience, corporations rarely make sane top-level technical decisions.
They read glossy magazines and get visits from sales-people instead ...
At some point these people will have to do something about vendor lock-in ...
Anyway, the grandparent wasn't suggesting that everybody should move to Linux. He suggested that if you have a sensible way of installing and updating installed software (using Linux package managers as an example) one of the often cited reasons for using crappy web apps goes away.
Then there's the third option: having the admins keep software installed in one copy (or one per OS and architecture) on a central file server, on a file system which everyone mounts. This has worked nicely since Sun invented NFS twenty years ago, and I cannot see why so many people refuse to use it today. Or does Windows prevent this too?
It's not the toolchain. He's an idiot (and you are too, for letting him do this.) You can use Visual Studio as a text editor and still interface the things you produce with what others produce (unless there are some DOS line ending or TAB quirks in VS). You cannot, of course, set up a VS build system, if all of the people you work with use Gnu Makefiles!
Rational sell IDEs now? Uh-oh ... *curls up in fetal position*
You're right, of course. With Emacs and Vim, you can have editor wars during coffee breaks, then go back to your editors of choice and work on the same code ...
But all this assumes that someone makes sure no moron ties the build system tightly into a specific IDE. And IDEs love to offer plenty of opportunities for this, and people who are in love with their IDE think this is the way it should be.
I've wondered that myself. Probably because few people understand the usefulness of name spaces, as a general concept. Or that their bosses think that if there's a dot in the name, it is a FQDN and has to end in .com ...
Also, as a general comment: if the hostname is harder to remember than the IP address, you are doing something wrong. As an end-user, I'd appreciate if the sysadmin didn't use the hostname as a general asset management database. The FQDN is a key into such a database, not a record.
Good advice, but it's worth pointing out that you can be much sloppier than that and get away with acceptable results.
I typically move two 100w bulb lamps to my desk, stand up with the book on the table, hold the book open with one hand, and take a picture with my camera in the other hand. Flip pages, and take another picture, and so on.
This is surprisingly fast (20 pages per minute or so) and works well for text and black-and-white illustrations, if all you want is to be able to read the text afterwards.
How about M-x set-default-font and (in ~/.emacs) (set-default-font "fontname")?
First, noone said it was more important. Secondly, expressiveness and conciseness are supposed to help during maintenance. I'd rather debug a complex Perl regex than the equivalent hand-written parser.
BTW, I use C++ daily, but I've never found a use for multiple inheritance. It's the spare tire in the trunk of my C++ car, and that was what it was designed to be.
And/or 3) something everyone except the boss knows is out-of-date and dangerous to refer to for anything important.
It's strange that the question explicitly asked for diagrams. What if this particular system is better described in plain text -- should there still be diagrams instead?
Apart from that I only have three pieces of advice:
I'm happy that they have made it work. Now let's see if people will start to use it in practice (i.e. branch more frequently).
According to earlier news, they would tap everything at the border, so if you had e.g. a .us--.us route or an .se--.se route which crossed the border,
your packets would be covered.
But some of us don't understand why we need to "move on" from a superior technology.
NNTP plus a good news reader still beats Slashdot and all other web forums in terms of usability/user-friendliness.
You have a point, but s/the top 50/the top 1000 or so/. You have to count various C libraries, and things like the Perl modules at CPAN. Many of them are in wide use, and should be trustworthy.
Also, I'm not so sure that community projects are generally better than single-person projects -- if you don't count crap projects which only the author can love.
That depends very much on where you're looking.
I'm sitting here with a traditional Unix installation (Debian Linux, with none of the Windows rip-off GUI thingies like Gnome and KDE), and all of it is free and excellent. In this area, it's the commercial alternatives that suck. If there are any.
You know, you didn't have to answer that question.
Yeah. And still, there are times and places for static typing.
I am not a novice Python programmer, but when my Python programs grow large enough, I find myself longing for a C++ compiler (with the warning level cranked up to the max of course, with C-style casts forbidden, and no unnecessary inheritance). Unit tests help a bit, but they never seem to be enough for me.
On the other hand, when my Python programs are fairly small (but non-trivial) Python's type system is great. And most of the things I do are fairly small ...
Of those languages, only Tcl has a longer history (as a well-known general-purpose language, at least) than Python. And lots of people find Tcl antiquated, primitive and ugly.
What Python offers is a free, high-level scripting language with a simple and elegant syntax, a good standard library, and strong, dynamic typing. It happens to be easy to write Python wrappers for C code too -- about as easy as Tcl, I'd say -- but it's hardly its main strength.
Well, not exactly. Some of those short cuts can be made in a clever way (as opposed to a "clever" way) so that an analysis can take less than a decade and still be useful.
At least that's roughly what a Polyspace salesman once told me.
I think you've missed something. Many (most?) good programmers have a drive to write elegant and correct code. It doesn't matter who pays them, or if they meet their peers by the corporate coffee machine or on a mailing list.
What's specific to corporate code ("open source" or propietary) is at least one thing: a manager can come up to you and say "you will code feature Foo and be done on date Bar", and the programmer will kludge it, even if he knows Foo cannot be done in a robust way, and the best option would be not to try at all.
Vonnegut was special because he had cred inside SF fandom, and he had cred as a "serious" author. I like him in principle, but secretly find him a bit tedious.
But come on! Unless you define "a good book" as "a book which an irrational SF hater would want to read", the question is meaningless. A bad story can never be a good SF story. We decide what is "good" and what isn't -- and we can happily ignore journalists and academics.
And you are saying Debian are special in this way? That RedHat, Novell (or whatever the commercial ones are called; I have lost track) don't? That the *BSDs don't? That the commercial Unices don't?
As far as I know, all of them apply their own patches (or others' patches) when they feel it's useful. The question is if you trust them to do it decently well, and in a way which suits you. For example, I agree with Debian's policy on writing man pages when the upstream didn't bother to do it.
AFAICS, no joke was implied. The poster truly believes somehow that a text mail client is more efficient over dialup.
That is fiction, of course. Downloading mail POP3-style works better over a slow line than IMAP-style mailbox access, but both GUI and text mail clients do both. Also, it is easy to make even Outlook send just the text. And you cannot prevent even the simplest reader from POPping HTML crap and Powerpoint attachments.
Web mail services like Gmail and whatever they are called are GUI-only and probably painful over slow lines, but you do not have to run Mutt or /bin/mail
to avoid them.
Not too bad, actually. You get a feel for the author's frame of mind when (s)he wrote that. I am guessing: reasonably clever, and aware that he writes for an audience -- but with a deadline coming up, and more urgent problems to deal with.