 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Except that (say) GIF supports animation and only 256 colours and 1-bit
> alpha, whereas PNG supports only single images, but with 24-bit colour
> and 8-bit alpha, and TIFF supports something else again...
Um, yes? So? You don't think you can abstract that? (BTW, GIF supports
more than that, as you can change the color table after each row. FWIW.)
>> No they're not. Amiga OS devices are things that listen for and
>> respond to typed messages. Certainly the narrator isn't a "stream of
>> octets", nor is the clock, nor is the audio device.
>
> The narrator accepts a stream of octets. It just interprets them as
> ASCII text and attempts to synthesize speach for them. But there's
> nothing stopping you from feeding it with arbitrary binary gibberish.
And the narrator, when read, returns discreet messages with X/Y
coordinates. Which isn't a stream of octets.
Of course, at some level of detail, everything is a stream of octets.
It's how the octets are interpreted that's interesting. At some level of
detail, everything's a voltage too - that's not an interesting level of
detail for this discussion either. :-)
>>> Oh, well, other than the "minor detail" of compatibility, there's no
>>> problem at all! ;-)
>>
>> Right. How much C is there that couldn't be ported with relative ease
>> to C#?
>
> Um... surely porting C code to *any* other language is intractably
> difficult?
Uh, no? Porting C code to C++ is actually fairly easy (almost trivial),
for example. C# isn't all that different from C, conceptually speaking.
>>> (You recall that "Linux" is actually a tiny bit of software which
>>> inherited compatibility with Unix, thus earning an instant library of
>>> userland tools, right?)
>>
>> Sure. Most of which suck. ;-) Just look at the file system layout you
>> wound up with.
>
> What, you mean assigning permissions only to the person that owns the
> file is a bad idea? You do surprise me. ;-)
No, I mean putting everything that hasn't anything to do with users in a
directory called "user" is probably a sign of legacy code. :-)
> But my point is... it's much faster than writing an entire OS from
> scratch, all by yourself. And it instantly gives you a huge library of
> usable software. Otherwise I suspect Linux would still be nowhere...
Oh, no doubt doing things the same old way makes it easier to port code.
Not always trivial, mind, but certainly easier. Most operating systems
that are still around are based on old cruft from 20 years ago for just
that reason. And obviously Linux didn't do a *sufficiently* good job of
it, or the amount of UNIX software that people actually want to use and
is portable is not enough to give Linux significant market share. It's
really, really difficult to make something that big *actually*
compatible. (See, for example, all the strangeness in any autoconf.)
It's probably almost as easy to port most non-GUI Linux utilities to
Windows as it is to port them to (say) Solaris. The port may be rather
poor (like, it might not interact with stuff the way you want it to
under Windows, such as not being startable with "net start" or not
recording how many unread emails you have for the login screen, say),
but it'll probably run as well as on Linux without too much hassle.
I'd guess things are way easier to port from UNIX to Windows than from
either to AmigaOS or Singularity, for example.
I think it's not so much that Linus T said "If I make it look like UNIX,
I can use all the tools." I think it was probably at least as much "If
I make it look like UNIX, I won't have to figure out how an OS *should*
work." Hence, it starts out with all the brokenness of UNIX, then
slowly piles on even more patches to try to make it useful, as long as
you're not trying to maintain binary compatibility anyway.
--
Darren New / San Diego, CA, USA (PST)
Ever notice how people in a zombie movie never already know how to
kill zombies? Ask 100 random people in America how to kill someone
who has reanimated from the dead in a secret viral weapons lab,
and how many do you think already know you need a head-shot?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> I think it's not so much that Linus T said "If I make it look like UNIX,
> I can use all the tools." I think it was probably at least as much "If
> I make it look like UNIX, I won't have to figure out how an OS *should*
> work." Hence, it starts out with all the brokenness of UNIX, then
> slowly piles on even more patches to try to make it useful, as long as
> you're not trying to maintain binary compatibility anyway.
The mental image of coding a broken system from scratch and then piling
more complexity on top really amused me for some reason.
I guess because it's so true. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The mental image of coding a broken system from scratch and then piling
> more complexity on top really amused me for some reason.
Welcome to the wonderful world of backward compatibility! :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The mental image of coding a broken system from scratch and then
>> piling more complexity on top really amused me for some reason.
>
> Welcome to the wonderful world of backward compatibility! :-)
"Darren puts the 'backwards' in 'backwards compatibility'." ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> "Darren puts the 'backwards' in 'backwards compatibility'." ;-)
Me? Heaven forbid. It's the bane of my career. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> And if you want to see how Singularity does this,
Actually, I kind of like their implementation of "compile time
reflection", which is sort of like C++ templates. You can pre-compile
them, ensure they'll work at compile time, and write templates in a
language different from the one you're using them in. Pretty funky.
Seems pretty straightforward, as well, and I'm guessing Turing complete
also, given you have the full power of the language available to
generate the code, without any weirdness necessary.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Aug 2008 14:27:48 -0700, Darren New wrote:
>>>>> Or "I can't let you install telnet[1] until you have some sort of
>>>>> TCP/IP stack installed."
>>>>
>>>> Isn't this what RPM does?
>>>
>>> No.
>>
>> Really? I thought that was the entire *point* of package managers.
>
> To some extent. Package managers tell you which dynamic libraries are
> needed for which programs. They don't enforce anything, and you cannot
> (for example) look at an RPM without installing it and know if it'll
> work right once you're done installing it.
Well, RPMs aren't package *managers*, they're packages. RPM is a package
manager, and it does a reasonably good job of enforcing dependencies -
you can override with --nodeps, but IME it does a good job for those who
need them enforced and lets those who know better if a dependency is
reasonable or not override.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Aug 2008 09:13:53 -0700, Darren New wrote:
> I think it's not so much that Linus T said "If I make it look like UNIX,
> I can use all the tools." I think it was probably at least as much "If
> I make it look like UNIX, I won't have to figure out how an OS *should*
> work." Hence, it starts out with all the brokenness of UNIX, then
> slowly piles on even more patches to try to make it useful, as long as
> you're not trying to maintain binary compatibility anyway.
Um, I think you'll find that Linux is a derivative of Minix, not UNIX.
At best it's Unix-like.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> it does a reasonably good job of enforcing dependencies -
There are relatively few kinds of dependencies it can enforce, and
nothing enforces that the dependecy declarations are correct, for
example. If the package doesn't allow it, the package manager isn't
going to be able to do it.
You cannot, for example, look at the list of packages installed on the
system and tell whether another package will install correctly - there
may be unwritable files in the way that aren't tracked by the package
manager, for example. The RPM may install files not listed in the
manifest, and may not install every file listed in the manifest. If the
package needs to add a user to the FTP server or something, there's
nothing in the RPM that lets you look at it and tell automatically that
adding that user will be necessary and needs to succeed before the
package is installed. There is nothing in an RPM, as far as I know, that
says which system services need to be enabled before you can start this
one. (Sure, it's in the init.d script, but that's not in the package
manifest, AFAIK.)
The Singularity package manager doesn't have this flaw, because the
manifest controls what gets installed. There's no shell script in the
package.
I'm not sure what you were trying to say with
> Well, RPMs aren't package *managers*, they're packages. RPM is a package
> manager,
I know that. That's what I was talking about. Nothing I said conflicts
with this, as far as I can see.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Aug 2008 14:57:25 +0100, Invisible wrote:
> Does anybody *else* find it ironic that Micro$oft - the corporation
> internationally renowned for its poor quality, buggy products - is
> interested in methods of producing high-quality software?
No. Well, at least, I don't.
I'm not a fan of Microsoft, *however* it doesn't surprise me that they
would look for ways to improve code quality without needing to invest
massive amounts of energy, time, and money to do so. Better production
methods are one way of accomplishing this goal.
I've always said that Microsoft is outstanding at producing software
that's "just good enough" - ie, it is buggy, but it's good *enough* that
people aren't flocking away.
That doesn't mean that they wouldn't/couldn't/shouldn't go through a
process of striving for continuous improvement in their development
processes. And clearly that's something they do (I've known people who
have worked in MS Engineering, so this isn't conjecture on my part - it's
based on conversations with former colleagues who worked at MS in that
capacity).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
