Reverse engineering is harder than working from published specs. It is establishing specs from the actual chip, then building it themselves.
AFAICT, the Intel stuff is no more "reverse engineered" from AMD64 than Linux is "reverse engineered" from Unix. It's simply another implementation of the spec.
You can argue that you can't accidentally license your work. But I'd argue when they continued to distribute Linux, having learned that it contained their copyrighted code, that they were deliberately and explicitly distributing their own code under the GPL.
Okay, good to know that SVG supports font embedding.
I find the addition of forms to SVG troubling because we already have open standards for that. I haven't been convinced (yet) that there's a need for another one. The bigger the standard, the harder it is to be compliant, and the less people will try.
When I say embedded files, I mean arbitrary embedded files that have no direct connection to the document's appearance. These things do exist in PDF, but I don't see a need for them in SVG. Data URLs don't cut the mustard, though. They only go to 1024 characters at 3 characters per 2 bytes.
That would make it contain less information than an equivalent PDF, since it would no longer contain the text-as-text. That would be unfortunate, since it would become less editable than a normal SVG or even a PDF document. One of the neat things about these standards is the fact that everything is editable.
PDF can reproduce a layout exactly, because it supports embedding fonts. AFAIK, SVG does not support embedding fonts, so reproducing a layout exactly would mean writing the font outlines as vectors.
PDF also support other functionality, such as forms and embedded files. SVG does a lot of what PDF does, but I really hope it doesn't become a PDF replacement, since a complete replacement would require such features.
"1.4. Things working: Pretty much everything, I hope. "
It's a wiki, not Word from On High
Re:10 revision control system comparison
on
Subversion 1.0 Released
·
· Score: 4, Informative
Note that at least some of this is out of date. For example, Arch has now been ported to win32.
Re:Does Subversion require a UNIX account per user
on
Subversion 1.0 Released
·
· Score: 4, Informative
Arch doesn't require any accounts for read-only access. Write access requires 1 account at minimum. If you want to have multiple people use the same account, that will work fine. (I'd recommend using ssh public-key authentication, though, since shared passwords are always bad policy)
Supported write protocols include webdav, sftp (the one that's part of ssh) and ftp. Shell access is never required.
Re:So whats better? AAC, WMA, MP3 or OGG?
on
Friday Apple Fun
·
· Score: 5, Insightful
Remember that on Unix-likes, you actually use three tools: tar, gzip and pgp. Zip handles both the file-archiving and file-compression concerns, and now the encryption too.
I can see definite positives in making it easy for GUI users to create secure compressed archives. It would be nice if there could be three best-of-breed tools that had a united GUI. But that would be cooperation, and that's not the Windows way.
What is wrong with that is that most of the code is correct and solid. It's just organised in the wrong way.
Instead of rewriting, restructure! When you rewrite, there's a period where the new code doesn't work. If you restructure in suitably-sized steps, the code always works between steps.
First of all, not all of these "rewrites" are actual rewrites. Win2k was not rewritten to produce XP. The HTML example he gives is self-contradictory. He writes positively about separation of content and presentation, then whines about CSS separating content and presentation.
The Netscae 4 codebase was better than 3, but it sucks compared to anything else people use today. Mozilla may take longer, but nested tables can freeze Netscape for minutes or hours.
If you think XUL's a problem, use Galeon, fer crying out loud.
You know what the worst part is? I agree with him. There are very few necessary rewrites. It's just a matter of knowing where you want to end up, and then figuring out how to get there from where you are. Doing it in stages means that you're never stuck with unready code, and most of it is well-tested by the time you're finished.
It's convenient. That way, you install any service you want to use locally, and update the firewall if you want to allow external access to the service.
I'm sure there's a way to configure bind so that it only listens for connections on the internal ethernet card, but the firewall covers everything, so I don't have to look up each app-specific way of controlling access.
Garfinkel says IPv6 has problems, but "NAT is really the devil".
"the apparent security that NAT provides is a mirage"
He says "NAT's one-way fence makes it harder for...Kazaa, but it's also a problem for Internet telephony and the next generation of multimedia groupware applications."
He concludes that sadly, IPv6 will be a long time coming.
You neglect the fact that high-level code *can* be optimized.
Any code can be optimized, but the question is whether it should. Code optimization (as opposed to compile-time optomization) should only be done where it has a noticeable impact on performance. Most code does not have an obvious impact on performance, and so it should be left alone, so it's more readable.
If your high-level code has a significant performance impact, it may not be as high-level as you believe.
If you accept the notions that 1. scripting languages speed development 2. high-level code does not need to be optimized
Then for an app like Neverwinter Nights, it would make sense to use a scripting language for the high-level code (e.g. menu handling code), while leaving the performance-critical code (e.g. 3-D rendering) in C, C++ or assembler.
Coded like this, NN might not crash as frequently because either - The crashy code would be implemented in a scripting language, and so memory handling would not be a problem
- The crashy code would still be in C/C++, but since the other code had been written more quickly, there would be more time to fix it.
The current issue of the C/C++ Users Journal is all about mixed-language development.
Slashdot Mirror
Reverse engineering is harder than working from published specs. It is establishing specs from the actual chip, then building it themselves.
AFAICT, the Intel stuff is no more "reverse engineered" from AMD64 than Linux is "reverse engineered" from Unix. It's simply another implementation of the spec.
Yeah. We're not talking about the app, though, are we? We're talking about the language the API is implemented in.
This isn't a discussion of what languages should be usable with GNOME. It's a discussion of what languages GNOME itself should be written in.
You can argue that you can't accidentally license your work. But I'd argue when they continued to distribute Linux, having learned that it contained their copyrighted code, that they were deliberately and explicitly distributing their own code under the GPL.
Okay, good to know that SVG supports font embedding.
I find the addition of forms to SVG troubling because we already have open standards for that. I haven't been convinced (yet) that there's a need for another one. The bigger the standard, the harder it is to be compliant, and the less people will try.
When I say embedded files, I mean arbitrary embedded files that have no direct connection to the document's appearance. These things do exist in PDF, but I don't see a need for them in SVG. Data URLs don't cut the mustard, though. They only go to 1024 characters at 3 characters per 2 bytes.
Yes, it could.
That would make it contain less information than an equivalent PDF, since it would no longer contain the text-as-text. That would be unfortunate, since it would become less editable than a normal SVG or even a PDF document. One of the neat things about these standards is the fact that everything is editable.
PDF can reproduce a layout exactly, because it supports embedding fonts. AFAIK, SVG does not support embedding fonts, so reproducing a layout exactly would mean writing the font outlines as vectors.
PDF also support other functionality, such as forms and embedded files. SVG does a lot of what PDF does, but I really hope it doesn't become a PDF replacement, since a complete replacement would require such features.
Does anyone know where to find the rsvg Mozilla plugin by Dom Lachowicz?
No, in my analysis,
Konspire2b is suboptimal.
The wiki also says:
"1.4. Things working: Pretty much everything, I hope. "
It's a wiki, not Word from On High
Note that at least some of this is out of date. For example, Arch has now been ported to win32.
Arch doesn't require any accounts for read-only access. Write access requires 1 account at minimum. If you want to have multiple people use the same account, that will work fine. (I'd recommend using ssh public-key authentication, though, since shared passwords are always bad policy)
Supported write protocols include webdav, sftp (the one that's part of ssh) and ftp. Shell access is never required.
FLAC.
Probably the easiest way to port it would be with libwine.
That's three pieces of tacky shareware.
Remember that on Unix-likes, you actually use three tools: tar, gzip and pgp. Zip handles both the file-archiving and file-compression concerns, and now the encryption too.
I can see definite positives in making it easy for GUI users to create secure compressed archives. It would be nice if there could be three best-of-breed tools that had a united GUI. But that would be cooperation, and that's not the Windows way.
Yes, but the OP was saying that it was especially likely in shops where people already had Mac skills.
Well, AVI is an implementation of RIFF, and that didn't come from MS.
Daily? Has /. been cutting back?
No. See today's story, for example. Oh, wait...
What is wrong with that is that most of the code is correct and solid. It's just organised in the wrong way.
Instead of rewriting, restructure! When you rewrite, there's a period where the new code doesn't work. If you restructure in suitably-sized steps, the code always works between steps.
First of all, not all of these "rewrites" are actual rewrites. Win2k was not rewritten to produce XP.
The HTML example he gives is self-contradictory. He writes positively about separation of content and presentation, then whines about CSS separating content and presentation.
The Netscae 4 codebase was better than 3, but it sucks compared to anything else people use today. Mozilla may take longer, but nested tables can freeze Netscape for minutes or hours.
If you think XUL's a problem, use Galeon, fer crying out loud.
You know what the worst part is? I agree with him. There are very few necessary rewrites. It's just a matter of knowing where you want to end up, and then figuring out how to get there from where you are. Doing it in stages means that you're never stuck with unready code, and most of it is well-tested by the time you're finished.
It's convenient. That way, you install any service you want to use locally, and update the firewall if you want to allow external access to the service.
I'm sure there's a way to configure bind so that it only listens for connections on the internal ethernet card, but the firewall covers everything, so I don't have to look up each app-specific way of controlling access.
Garfinkel says IPv6 has problems, but "NAT is really the devil".
"the apparent security that NAT provides is a mirage"
He says "NAT's one-way fence makes it harder for...Kazaa, but it's also a problem for Internet telephony and the next generation of multimedia groupware applications."
He concludes that sadly, IPv6 will be a long time coming.
You neglect the fact that high-level code *can* be optimized.
Any code can be optimized, but the question is whether it should. Code optimization (as opposed to compile-time optomization) should only be done where it has a noticeable impact on performance. Most code does not have an obvious impact on performance, and so it should be left alone, so it's more readable.
If your high-level code has a significant performance impact, it may not be as high-level as you believe.
If you accept the notions that
1. scripting languages speed development
2. high-level code does not need to be optimized
Then for an app like Neverwinter Nights, it would make sense to use a scripting language for the high-level code (e.g. menu handling code), while leaving the performance-critical code (e.g. 3-D rendering) in C, C++ or assembler.
Coded like this, NN might not crash as frequently because either
- The crashy code would be implemented in a scripting language, and so memory handling would not be a problem
- The crashy code would still be in C/C++, but since the other code had been written more quickly, there would be more time to fix it.
The current issue of the C/C++ Users Journal is all about mixed-language development.
In C and C++, "double" is implementation-defined. So a double will always be compiled into a double, but that's a tautology.