On Wed, Jul 28, 2004 at 12:55:49PM -0400, Derek Glidden wrote:
>
> On Jul 27, 2004, at 10:16 PM, Paul M Foster wrote:
>
> >I just noticed that many Debian packages now include "dfsg" in the name
> >of the actual .deb files. What is this? A search of the Debian list
> >archives turns up more non-useful data than I can shake a stick at, and
> >google isn't any better. Does this have something to do with Debian's
> >complaints about X's license?
>
> Ugh...
>
> Can I just list this as "Yet Another Reason I've Dumped Debian In Favor
> Of A Different Distro That Isn't More Concerned With Semantics,
> Politics And Splitting Hairs As It Is About Just Making The Damn Thing
> Work"?
>
> I guess I should give kudos to the Debian development team for deciding
> NOT to implement the new DFSG "standards" BEFORE releasing the next
> "stable" version of the distro and pushing the release date back yet
> another 16 years.
>
> I never thought I'd see the time when distros took longer to cycle than
> major kernel releases.
>
> Paul, maybe you should take a serious gander at Gentoo. I've pretty
> much converted entirely at this point, and will be totally debian-free
> as soon as I can decomission the current illusionary.com and put its
> replacement online. So far I've been really happy with it. It has the
> same "keep your hands off my config files" sysadmin mentality that
> attracted me to Debian, but without all the political baggage.
Yeah, Rob Mayhue's been singing the praises of Gentoo for years. I'm
just not that keen on learning curves at this point, and I've had more
than one compile go bad on me. But I have been thinking in this
direction.
I have to agree about Debian politics, though. Sadly, I've argued with
these people about this, and it's more like arguing religion than
anything else. They've gotten so snippy about this "non-free" thing that
they're even dropping RFCs and some man pages. Argh! It seems to be an
example of being so slavish to the rules that they are unable to grasp
the purpose behind them. And change the rules when they get in the way
of the purpose.
<snip>
> Microsoft did something right for once. They got the CLR (Common
> Language Runtime) part of this whole .NET mess right and it's something
> I'm very jealous of as a Java programmer who is getting so over all of
> Java's... umm, let's call them idiosyncrasies for PC-ness. The fact
> that Mono implements this on platforms other than Windows has me very
> interested.
>
I'm just waiting for Microsoft to patent/copyright/trademark the .NET
framework, and then sue Mono out of existence. I've been waiting a while
for this, and I think it's odd it hasn't happened yet. That's why I
wouldn't want to invest a lot in Mono; I don't don't think it will
survive an inevitable Microsoft onslaught.
I assume that apps written for Mono will run on .NET and vice versa?
That seemed to be the point when Mono was started. If so, I'd expect
Microsoft to embrace and extend its own framework in such a way that one
day, Mono has to be reworked because suddenly Mono apps won't run on
.NET. Or vice versa.
Somehow I just can't see Microsoft being so altruistic that they would
come up with a true cross-platform way to write apps anywhere and run
them everywhere. Not if Microsoft's not getting a piece of the action on
every app, maybe every time you run it.
<snip>
> I'd LOVE to have a cross-platform VM that will run my byte-compiled
> Perl, Python, Java, LISP, Ruby, Eiffel, Modula, C/C++ or even shellcode
> all in the same VM and able to communicate with each other through
> mechanisms less complicated than having to write native-language (i.e.
> C) interfaces. At one point, this interface was supposed to be this
> CORBA stuff, which also had the benefit of being network-transparent,
> but if anyone can point out a less intuitive, less performant way of
> getting components in multiple languages to talk to each other, I'd
> love to know. And thus, other than some dedicated weirdos (who either
> invested too much time in learning, or have too much legacy code that
> needs it) CORBA is dead, dead, dead because of it's inherent
> complexity, slowness and overall braindeadedness.
>
You just set down a grenade in the vicinity of Ronan. I'm going behind a
tree to wait for it to go off. ;-}
> The way Gentoo handles it, pushing the compilation step down to the
> individual machines, you're not only optimizing for your particular
> architecture, but through the "USE" settings, you're optimizing for the
> particular settings on that individual machine. It's not that big a
> deal for people familiar with the "configure; make; make install" cycle
> of most open-source software as it is; it just streamlines the process
> and makes it easier for people to do the "configure; make; make
> install" without having to know all the switches for every single app
> you want to install.
>
You realize, of course, that this will work for some geeks (not all) and
not at all for Windows types. They just want to run an installer and
then have their app appear on the desktop. Yes, I suppose you could wrap
"configure; make; make install" in an installer. But that just
multiplies the ways in which things could go wrong.
<snip>
> And in ten years or so, much less fifty or a hundred, I'm betting that
> virtually _every_ piece of software is going to be distributed as some
> kind of bytecode or semi-compiled code and compiled natively at
> run-time to be optimized for the particular architecture and platform,
> not just the usual .tar.bz2 type we OSS types are already comfortable
> with.
Actually, it seems more reasonable to simply microcode the bytecode into
some Transmeta chip (the way they emulated the x86 on the Crusoe) and
have the machine just run the bytecode natively.
Paul
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 13:32:00 EDT