[sclug] Upgrading and languages (was: Who has the key to your Vista PC?)
ed
ed at s5h.net
Wed Feb 7 19:08:29 UTC 2007
On Wed, 07 Feb 2007 01:21:31 +0000
Will Dickson <wrd at glaurung.demon.co.uk> wrote:
> ed wrote:
>
> > the manufacturing process is expensive, but why are we upgrading
> > anyway? why doesnt software become *MORE* efficient with time,
> > rather than less? seems daft to me, programmers get more skilful
> > over time, why don't they write with c more than with c#? surely
> > it's better to become more sophisticated rather than less.
> >
> > probably boils down to money..
>
> One tends not to notice it, because the changes are incremental, but
> all that extra weight is actually there for a reason.
i dont know about that. i mention this all the time to people who pay
for software, particularly containing the MS brand. i particularly drag
my feet with these upgrades, if there is something else available
that's free, i push that.
> Concrete example: a long time ago (before I saw the light :-), I
> bought VC++ 6. At the time, I considered it a) a pretty good IDE; and
> b) HUUUGE! - it was the biggest application on my box by far,
> although I might have had 1 or 2 games which had bigger overall
> footprints.
vc++ 6 did seem like a big thing at the time. it contained a bunch of
languages and promised the world. but it just didnt stand up to all the
hype.
borland builder was pretty much just as good. if i knew then how to use
vim, i would have just used the watcom compiler and do my own edits.
> And then, quite recently, I rebuilt my GameOS installation on a new
> box, and reinstalled exactly the same VC++ 6 as part of the deal (I
> still have a small amount of GameOS code to support). Results: a)
> "good *grief*, how did I ever tolerate this featureless POS?" and b)
> "is that it? Where's the rest of it?"
>
> These two are interconnected!
you really shouldn't punish a perfectly good computer like that. since
getting into linux/unix style things, almost every thing i do is
command line based, no guis, if you think in these terms, try devc++,
it's a reasonable editor and has compile short cuts.
if you're a vi person, typing :make pretty much replaces everything
a whole menu in vc++.
> As to the languages thing (just a sec while I get my asbestos suit
> on):
>
> - C is very powerful at the lowest levels. If you're writing kernels,
> device drivers, or other Really Wild Stuff, you use C because the
> only alternative is assembler. Pretty much nothing else cuts it.
i dunno about that. pascal can execute and compile faster than c. at
least that's how i remember it. turbo pascal was much nicer to use than
turbo c (which, no one should use these days).
> - C is bloody awful for writing large, reasonably run-of-the-mill
> application code. You don't need its bit-twiddling abilities here.
> What you do need is plenty of abstractive power (so you can get the
> job done inside the silly schedule which manglement have just handed
> you) and the ability to eg. not have to spend half your mental
> run-time worrying about low-level memory management. (See "buffer
> overrun".) That's the sort of menial labour which, in most cases,
> computers with well-written language runtimes (which yes, probably
> *are* written in C - these fall under "Really Wild Stuff" for the
> purposes of this argument) are a lot better at than humans.
you can do the abstraction in c using structs and function pointers.
> - In other words, you need a high-level language. There are plenty
> around, but C is not one of them and never was - it was defined as a
> "middle-level language", somewhere between the high-level languages
ah, no, c *was* the high level language.
asm/machine code - low level
pascal - medium level
c - high level.
when c++ came on the scene, c promptly moved into mid level.
now we have java/c# (not *real* languages) have stepped into the high
level order and most of the other things are in mid.
> proper, and low-level assembler code. IMNSHO the mission creep which
> C has experienced over the years, as it spread from stuff it was good
> for (writing most of unix) via stuff it was reasonably good for
> ("middleware" in a very broad sense) to application-level code for
> which it was never intended, is one of the major reasons why we've
> all seen so much losing, bug-infested application code over the years.
the bugs are just from people not checking what they're doing. the
language is fine, if one is ok with the API.
> > i'm sure we're all working in our favourite wm right now, for me,
> > xfce, loads of functionality. no beryl or anything running, i like
> > it 2d, but its and infinitely more efficient way to work than in
> > explorer.exe, which is limited.
>
> Which reminds me - does anyone know of a way to do a GUI-compatible
> su under XUbuntu to change to a user other than root? I've tried
> several mechanisms, and they all allow me to launch GUI apps as root
> with no problem, but won't work if I try to launch said GUI apps as
> some other user. This is a bit of a pain, since XUbuntu would be
> ideal for our various servers if only I could get this to work.
i'm not sure i understand the question, but you may want to look at the
'visudo' program, which allows one to modify the sudoers file.
> > the users will notice only that there are some
> > interface changes and the functionality really is just about the
> > same as it was in 2000.
>
> I'm wondering how long it'll take for DirectX 10-only games to come
> out? The only way I'd get Vista would be if either nVidia stop making
> Windows2000 drivers to satisfy my OTT-graphics-card habit, or if some
> really, really must-have game came out which was Vista-only. I've
> managed to avoid downgrading from W2K to XP so far; with a bit of
> luck I'll be able to dodge Vista as well :-)
i never got past 2000. from then on it was linux all the way, hook it
to a vein!
pretty sad in some people's eyes, but i'm liberated.
--
The bread crumbs to the mcu is paging like Tristan because of
unscheduled testing of the battery backup system. Sun Microsystems is
trying to be EBITDA positive by the end of the year
More information about the Sclug
mailing list