Furthermore, this company JUST released this product, did they not? According to the GPL a company is not obliged to release their sourcecode, unless they DISTRIBUTE it. In other words, if they just started distributing this past week, it's still reasonable for them to take awhile longer to reply.
They released the software in binary form months ago. They refused to make the source available at the time (probably while they were trying to get licensees). Months later the source appeared on their web site. They licensed the software to a hardware manufacturer and the hardware manufacturer apparently released a hardware product recently.
Not having read the GPL but does it say how long a company has to release the source?
If the binary is available for download, the source must be available for download from the same location at the same time.
Also who knows...that source you got could actually be the kernel in your system...a mess or not..sometimes shitty code actually works.
The GPL is pretty explicit that they need to include the source in the form they are using for making the executable. My impression is that this is not the case.
There have been lots of different versions of the "real Bourne shell" over the years. From a practical point of view, you should have no problem writing scripts that run in bash and in whatever shell you consider "real". Stick to the POSIX specs where possible.
However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.
Ada supports garbage collection, but doesn't mandate it in the language standard.
That's a meaningless statement--in that sense, every language supports garbage collection.
The genericity model (which uses explicit instantiation) makes it a bit easier to write good generics than other approaches (for example, implicit instantiation used by C++). In addition, non of the other languages you cited support generics at all.
The module system is rather unique in its facilities to ensure that all modules are initialized in the correct oder. Most programming languages do not address the problem of initialization at all.
This is 2001, not 1980. Genericity and modules in languages like ML are far more advanced and better designed than in Ada.
Implicit instantiation in C++ and its interaction with overloading is a very powerful facility that goes far beyond genericity. It's a bit related to classes in Haskell. It has some problems the way it is implemented in C++, but the facility will likely become more prevalent in modern languages.
Ada isn't bad for what it is. But it is showing its age and programming language technology has moved on--we really do know how to design better languages by now.
The AgendaVR, Yopy, and Sharp PDAs are "Linux PDAs". This is a proprietary PDA that happens to use a Linux kernel. Other than that, you'll have an easier time writing applications using open source tools for the Palm than for this thing.
What bugs me about this is not that some company is using the Linux kernel to build a proprietary PDA, but the fact that they so prominently use the Linux name. This is not a "Linux" PDA in any useful sense: it doesn't run Linux utilities, it thumbs its nose at the open source process, and even its kernel software development appears to take part outside the Linux community.
I also wonder whether the company even still has the right to use the Linux kernel. They failed to make source code available for months (I requested it), even though they were distributing binaries. That was a violation of the GPL, and once you violate it, you lose the right to use the code. Also, the source code that they did finally distribute is a mess, and I have my doubts that it even corresponds to the kernel that they ship, which would constitute another GPL violation.
That may well be, but it doesn't really affect the argument. Journaling imposes an additional set of constraints on when and where data needs to be written to disk, and an optimal file system designed under those constraints is going to have more overhead than an optimal file system designed without those constraints. Generally, with journaling, either you write the same data multiple times sooner or later (which, I believe, ext2 does), or you put data in places where it may take longer to get to when reading it.
The only time where journaling doesn't have any significant overhead is if you put the journal on another device that can operate in parallel.
Those are all the usual arguments. However, if you want reliability and avoid downtime, you must have redundant servers or replication; journaling will not protect against most of the problems that cause downtime. Once you have redundant servers, you can easily tolerate a little more time for fsck.
What it comes down to is that journaling is a convenience feature. Relying on it for "filesystem integrity" or "reduced downtime" or "reliability" is foolish. You pay for fast reboots in slower performance and more complex file system code.
Journaling insures filesystem integrity, which is very important. Mounting an unclean ext3 fs will take seconds - no need to check the filesystem for mid-write evidence, etc.
Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.
I pulled it over and installed it. Running their own benchmarks, it seems 5-10x slower than C on most benchmarks. Also, looking more at the documentation, this is not merely a "safe version of C", it's a pretty complex language with C-like syntax but many ML-style features.
Cyclone could be a winner if it gave you C-like performance with safety and minimal changes to your programs. But it doesn't match C performance as it is and I don't think large, existing C programs will port to it easily, despite superficial similarities.
The way it is, I think you are better off using O'CAML or MLton. They are probably easier to learn and give you better performance. O'CAML, in particular, has already been used for a number of UNIX/Linux utilities. And Java is probably as C-like as Cyclone and runs faster (although programs have a bigger footprint).
The range supported from access point to client in an 11M-bit/sec network is about 300 feet.
Not from any 802.11b product I have ever encountered. In fact, the existing 802.11b products I have tried are lucky to get anywhere near 90 ft in a real-world environment.
I think whether 802.11a will be better or worse than 802.11b in real life remains to be seen. If its theoretical range is shorter it may actually work better in practice because there is less interference from neighboring users. And the 5GHz band is a lot less busy than the 2.4GHz band.
Yes, it looks like C --> C++ --> Java --> C# is on a trajectory that is converging toward Ada.
Ada may still be a good language for its intended application domain, but it is rather off on the sidelines when it comes to language evolution.
Java has many features Ada lacks, including reflection, dynamic code generation, garbage collection, sandboxing, and dynamic loading. OTOH, Java does not permit untraced pointers or unsafe code. And Ada's genericity, module system, and process model are rather outdated.
For the same reason, you can't create a valid URL reliably (see your posting), other people can't write correct pointer code: people make mistakes. And C software is full of such mistakes--just take a look at the various bug trackers.
Your assertion that this is for "lazy" programmers recognizes that avoiding or fixing pointer bugs takes time and effort. Programmers spend a certain number of hours per day programming. They can spend those hours avoiding or fixing pointer bugs, or they can spend those hours improving the UI, fixing other bugs, or creating entirely new applications. I find the latter much more useful than the former.
The whole purpose of computers is to automate repetitive operations, and ensuring pointer safety seems like a very repetitive operation to me, and one that everybody makes mistakes on.
I find Ada to be pretty awful for what I am doing, even compared to C++: it just takes too damned long to get anything done in it. Maybe that works for very expensive, very slow-moving defense projects, but I think it doesn't work well for fast-paced industrial or open source projects.
But just because Ada is like that doesn't mean every safe systems programming language has to be like that. Modula-3 is a whole lot nicer than Ada. Sather is a whole lot nicer than Ada. And there are other examples of safe systems programming languages.
I think Cyclone has a good chance to deliver safer systems programming to C programmers in a package that they find palatable.
Pointer arithmetic and similar features of C were introduced under some pretty tight constraints. After all, C compilers needed to run on the PDP-11 and work in 64k of address space.
But on modern architectures, many of these design decisions are not that sensible anymore. For example, pointer arithmetic is more of a burden to modern optimizers. Languages that don't have pointer arithmetic but use array notation instead usually do as well as C in terms of performance, and often better. Similarly, the many unsafe operations in C, like "*(double *)&x" are better expressed using something that is syntactically distinguishable from a safe operation, say, "unsafe_get_bits(x,double)"; doing so involves no loss of functionality.
But language success involves a lot of psychology. Java is much more like Lisp than like C++, yet people think of it differently because of its syntax. And if it takes Cyclone to get C programmers to program in what amounts to Modula-3, so be it--the world will be better off for it.
Apple holds a lot of patents and, from what I've seen so far, are fairly reasonable about opening them up. Of course they still want to hold on to their intellectual property, but they have opened up patents in the past for reasonable use.
But it isn't their intellectual property: they applied for a patent on a 20 year old textbook technique. Apple is doing the equivalent of just taking land that belongs to the public. Letting a few pedestrians through every now and then doesn't make that "reasonable".
There is only one reasonable thing to do for Apple: dedicate the patent to the public domain as quickly as possible.
The patent statement was last updated in July, and in October Apple made a public statement that they would no longer support any patent agreement for web standards except royalty-free. Does anyone else see problems in the reporting here?
How nice if Apple stopped pestering the SVG group about it for some strategic reason (most likely that their patent portfolio is smaller than that of other companies, so they would lose under RAND). But that doesn't really address the more basic issues.
Has Apple dedicated the patent to the public domain? What posessed them to assert rights in this patent to the SVG group a few months ago in the first place? Why did the "inventors" apply for a patent on a textbook technique in 1992, decades after the technique was invented?
This isn't irrelevant--it still tells us lots about Apple's attitude towards intellectual property.
That's a good reference. There may be other, earlier references, though: it's not unusual for the computer graphics community to reinvent techniques that were previously already known in the signal and image processing communities.
But first, you've argued that people shouldn't use CL because it won't work well for them. Yet if it works well for people who choose to use it, your reasoning becomes circular. Which is it?
I never argued that people "shouldn't" use CommonLisp. I stated that I and other experienced CommonLisp users stopped using CommonLisp because it wasn't helping us get our work done as well as other tools.
You seem to think if you find some Lisp with some deficiency that you can attribute it to all Lisps.
I have not attributed any deficiencies to "all Lisps". I mean, come on, the whole thread is entitled "it's not a problem with Lisp". I attributed specific deficiencies to CommonLisp.
I think we should end the debate here. You keep responding to positions I have not taken and we evidently keep talking past each other on the technical issues.
Alpha compositing is in Foley and van Dam's second edition (1990, p835-840), and it is almost certainly also in the first edition, which I don't even have anymore. My guess is that people came up with this some time in the 1960's. Foley and van Dam even talk about subpixel issues and tree-based representations in compositing. Not that any of this shouldn't be obvious to any reasonably intelligent CS undegraduate anyway.
I think this leaves only two possible conclusions: either Apple's legal staff and the inventors, Konstantin Othmer and Bruce Leak, are completely incompetent, or the inventors deliberately tried to patent a technique they knew to be in wide use and Apple's legal staff is deliberately trying to enforce an invalid patent. Apple didn't even have the smarts to offer this patent for "royalty free" licensing to SVG.
Forget about any of Apple's claims of openness: this is such a clear case of patent abuse that it can't be an accident or mistake. The open source community would do well to stonewall Apple: don't incorporate OSX-related patches into open source projects, don't port to their hardware, and don't buy their products.
Already [operating system independence] shows itself to be of value to our community, so I'm not sure what you mean here.
Of course, whatever CommonLisp does works well for the people who are using it, otherwise they wouldn't be using it. Given that the CommonLisp user community is small compared to the C/C++, Java, Perl, and Python communities, however, that is not a validation for that approach--it may just be that the needs of current CommonLisp users are modest. People write cross-platform programs in those other languages regularly, which, for the most part, take very different approaches to operating system integration.
I am still awaiting a concrete example of a design decision that [the CommonLisp standards body] made in the name of its desire to endure that seems unwise and indefensible to you.
There are two questions. The first is whether the CommonLisp standards body should have done things differently given what they knew at the time. I don't want to debate that.
The second is whether the CommonLisp standard is a good standard for software development for most people in 2001. To me, the answer is "no". There are many issues that went into the design of the CommonLisp standard that are simply not relevant anymore, even if they were arguably issues in the 1980s, and there are many other issues that are not being addressed by the CommonLisp standard.
Just take character sets, for example. The CommonLisp standard allows for things like TENEX and the Lisp machine, but it fails to define many of the functions we expect for dealing with modern character sets. A modern Lisp standard should most likely simply specify Unicode. No Lisp standards body could hope to do a better job on character sets, portability to a few remaining oddball systems with different native character sets can still be achieved via canonicalization at the system boundaries, and if 20 years from now, another character set comes along, experience from other languages shows that changing over is not a big deal.
The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro.
I'm not sure what your beef is with the ANSI C standard. Let's look at character sets again. Until Unicode, 8bit ASCII (and later ISO) was the de-facto standard for many, but not all, C programmers. If you wanted to write character set independent code, ANSI C provided a set of abstract functions. And C was designed in such a way that you could define your own character set and operations that were in every regard as efficient and functional as the built-in ones. ANSI C got this right: it gave developers the choice between system independence and simplicity, and as you yourself observed, most developers didn't give a damn about system independence.
CommonLisp, on the other hand, only covers one of those three approaches: it only has a set of abstract operations, but it never really got a de-facto character set standard and it lacks value types, keeping users from defining their own efficient character datatypes.
It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view.
Why you continue to use the term "Lisp" to refer to one particular dialect baffles me. Do you really consider CommonLisp synonymous with Lisp? I am a regular user of several dialects of Lisp, but I largely stopped using CommonLisp. To me, Scheme is as different from CommonLisp as, say, ML is from C++.
Slashdot Mirror
They released the software in binary form months ago. They refused to make the source available at the time (probably while they were trying to get licensees). Months later the source appeared on their web site. They licensed the software to a hardware manufacturer and the hardware manufacturer apparently released a hardware product recently.
Well, I asked, and they didn't make it available in any form for several months.
The one for the distribution you are targetting. If you target multiple distributions, use the native packaging system on each.
The Linux packaging system for each of the distribution(s) you are targetting. That means packaging each for Debian, RedHat, and possibly others.
If the binary is available for download, the source must be available for download from the same location at the same time.
Also who knows...that source you got could actually be the kernel in your system...a mess or not..sometimes shitty code actually works.
The GPL is pretty explicit that they need to include the source in the form they are using for making the executable. My impression is that this is not the case.
However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.
That's a meaningless statement--in that sense, every language supports garbage collection.
The genericity model (which uses explicit instantiation) makes it a bit easier to write good generics than other approaches (for example, implicit instantiation used by C++). In addition, non of the other languages you cited support generics at all. The module system is rather unique in its facilities to ensure that all modules are initialized in the correct oder. Most programming languages do not address the problem of initialization at all.
This is 2001, not 1980. Genericity and modules in languages like ML are far more advanced and better designed than in Ada.
Implicit instantiation in C++ and its interaction with overloading is a very powerful facility that goes far beyond genericity. It's a bit related to classes in Haskell. It has some problems the way it is implemented in C++, but the facility will likely become more prevalent in modern languages.
Ada isn't bad for what it is. But it is showing its age and programming language technology has moved on--we really do know how to design better languages by now.
Well, I didn't make that claim. In fact, I gave the VR3 as an example of what I would consider a true Linux PDA, as opposed to to the "Linux DA".
In fact, I like my VR3 a lot. The only thing it really needs is an MMC expansion slot.
Forgot to turn on the brain again?
What bugs me about this is not that some company is using the Linux kernel to build a proprietary PDA, but the fact that they so prominently use the Linux name. This is not a "Linux" PDA in any useful sense: it doesn't run Linux utilities, it thumbs its nose at the open source process, and even its kernel software development appears to take part outside the Linux community.
I also wonder whether the company even still has the right to use the Linux kernel. They failed to make source code available for months (I requested it), even though they were distributing binaries. That was a violation of the GPL, and once you violate it, you lose the right to use the code. Also, the source code that they did finally distribute is a mess, and I have my doubts that it even corresponds to the kernel that they ship, which would constitute another GPL violation.
The only time where journaling doesn't have any significant overhead is if you put the journal on another device that can operate in parallel.
What it comes down to is that journaling is a convenience feature. Relying on it for "filesystem integrity" or "reduced downtime" or "reliability" is foolish. You pay for fast reboots in slower performance and more complex file system code.
Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.
Cyclone could be a winner if it gave you C-like performance with safety and minimal changes to your programs. But it doesn't match C performance as it is and I don't think large, existing C programs will port to it easily, despite superficial similarities.
The way it is, I think you are better off using O'CAML or MLton. They are probably easier to learn and give you better performance. O'CAML, in particular, has already been used for a number of UNIX/Linux utilities. And Java is probably as C-like as Cyclone and runs faster (although programs have a bigger footprint).
Not from any 802.11b product I have ever encountered. In fact, the existing 802.11b products I have tried are lucky to get anywhere near 90 ft in a real-world environment.
I think whether 802.11a will be better or worse than 802.11b in real life remains to be seen. If its theoretical range is shorter it may actually work better in practice because there is less interference from neighboring users. And the 5GHz band is a lot less busy than the 2.4GHz band.
Ada may still be a good language for its intended application domain, but it is rather off on the sidelines when it comes to language evolution.
Java has many features Ada lacks, including reflection, dynamic code generation, garbage collection, sandboxing, and dynamic loading. OTOH, Java does not permit untraced pointers or unsafe code. And Ada's genericity, module system, and process model are rather outdated.
Your assertion that this is for "lazy" programmers recognizes that avoiding or fixing pointer bugs takes time and effort. Programmers spend a certain number of hours per day programming. They can spend those hours avoiding or fixing pointer bugs, or they can spend those hours improving the UI, fixing other bugs, or creating entirely new applications. I find the latter much more useful than the former.
The whole purpose of computers is to automate repetitive operations, and ensuring pointer safety seems like a very repetitive operation to me, and one that everybody makes mistakes on.
Seriously, I hope they'll start packaging Cyclone for Debian as well. That's a good way to get more exposure for it.
But just because Ada is like that doesn't mean every safe systems programming language has to be like that. Modula-3 is a whole lot nicer than Ada. Sather is a whole lot nicer than Ada. And there are other examples of safe systems programming languages.
I think Cyclone has a good chance to deliver safer systems programming to C programmers in a package that they find palatable.
But on modern architectures, many of these design decisions are not that sensible anymore. For example, pointer arithmetic is more of a burden to modern optimizers. Languages that don't have pointer arithmetic but use array notation instead usually do as well as C in terms of performance, and often better. Similarly, the many unsafe operations in C, like "*(double *)&x" are better expressed using something that is syntactically distinguishable from a safe operation, say, "unsafe_get_bits(x,double)"; doing so involves no loss of functionality.
But language success involves a lot of psychology. Java is much more like Lisp than like C++, yet people think of it differently because of its syntax. And if it takes Cyclone to get C programmers to program in what amounts to Modula-3, so be it--the world will be better off for it.
But it isn't their intellectual property: they applied for a patent on a 20 year old textbook technique. Apple is doing the equivalent of just taking land that belongs to the public. Letting a few pedestrians through every now and then doesn't make that "reasonable".
There is only one reasonable thing to do for Apple: dedicate the patent to the public domain as quickly as possible.
How nice if Apple stopped pestering the SVG group about it for some strategic reason (most likely that their patent portfolio is smaller than that of other companies, so they would lose under RAND). But that doesn't really address the more basic issues.
Has Apple dedicated the patent to the public domain? What posessed them to assert rights in this patent to the SVG group a few months ago in the first place? Why did the "inventors" apply for a patent on a textbook technique in 1992, decades after the technique was invented?
This isn't irrelevant--it still tells us lots about Apple's attitude towards intellectual property.
That's a good reference. There may be other, earlier references, though: it's not unusual for the computer graphics community to reinvent techniques that were previously already known in the signal and image processing communities.
I never argued that people "shouldn't" use CommonLisp. I stated that I and other experienced CommonLisp users stopped using CommonLisp because it wasn't helping us get our work done as well as other tools.
You seem to think if you find some Lisp with some deficiency that you can attribute it to all Lisps.
I have not attributed any deficiencies to "all Lisps". I mean, come on, the whole thread is entitled "it's not a problem with Lisp". I attributed specific deficiencies to CommonLisp.
I think we should end the debate here. You keep responding to positions I have not taken and we evidently keep talking past each other on the technical issues.
I think this leaves only two possible conclusions: either Apple's legal staff and the inventors, Konstantin Othmer and Bruce Leak, are completely incompetent, or the inventors deliberately tried to patent a technique they knew to be in wide use and Apple's legal staff is deliberately trying to enforce an invalid patent. Apple didn't even have the smarts to offer this patent for "royalty free" licensing to SVG.
Forget about any of Apple's claims of openness: this is such a clear case of patent abuse that it can't be an accident or mistake. The open source community would do well to stonewall Apple: don't incorporate OSX-related patches into open source projects, don't port to their hardware, and don't buy their products.
Of course, whatever CommonLisp does works well for the people who are using it, otherwise they wouldn't be using it. Given that the CommonLisp user community is small compared to the C/C++, Java, Perl, and Python communities, however, that is not a validation for that approach--it may just be that the needs of current CommonLisp users are modest. People write cross-platform programs in those other languages regularly, which, for the most part, take very different approaches to operating system integration.
I am still awaiting a concrete example of a design decision that [the CommonLisp standards body] made in the name of its desire to endure that seems unwise and indefensible to you.
There are two questions. The first is whether the CommonLisp standards body should have done things differently given what they knew at the time. I don't want to debate that.
The second is whether the CommonLisp standard is a good standard for software development for most people in 2001. To me, the answer is "no". There are many issues that went into the design of the CommonLisp standard that are simply not relevant anymore, even if they were arguably issues in the 1980s, and there are many other issues that are not being addressed by the CommonLisp standard.
Just take character sets, for example. The CommonLisp standard allows for things like TENEX and the Lisp machine, but it fails to define many of the functions we expect for dealing with modern character sets. A modern Lisp standard should most likely simply specify Unicode. No Lisp standards body could hope to do a better job on character sets, portability to a few remaining oddball systems with different native character sets can still be achieved via canonicalization at the system boundaries, and if 20 years from now, another character set comes along, experience from other languages shows that changing over is not a big deal.
The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro.
I'm not sure what your beef is with the ANSI C standard. Let's look at character sets again. Until Unicode, 8bit ASCII (and later ISO) was the de-facto standard for many, but not all, C programmers. If you wanted to write character set independent code, ANSI C provided a set of abstract functions. And C was designed in such a way that you could define your own character set and operations that were in every regard as efficient and functional as the built-in ones. ANSI C got this right: it gave developers the choice between system independence and simplicity, and as you yourself observed, most developers didn't give a damn about system independence.
CommonLisp, on the other hand, only covers one of those three approaches: it only has a set of abstract operations, but it never really got a de-facto character set standard and it lacks value types, keeping users from defining their own efficient character datatypes.
It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view.
Why you continue to use the term "Lisp" to refer to one particular dialect baffles me. Do you really consider CommonLisp synonymous with Lisp? I am a regular user of several dialects of Lisp, but I largely stopped using CommonLisp. To me, Scheme is as different from CommonLisp as, say, ML is from C++.