The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.
Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.
Dynamic linking is treated the same as static linking, which is why the LGPL exists.
How about you go branch your own Linux kernel tree and add code back in that better supports binary-only modules?
Well, he'd have to be careful there, since some copyright holders might take issue if the changes amounted to a relicensing, but sure, he could maintain his own tree if he liked, and never change it so that binary modules never break. Of course it would never get better either...
"This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task."
What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.
Err. Many (or perhaps even most) companies have already made major investments in Linux. And your point is?
If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible..
They are not. If the modem driver already runs under a wrapper, then updating the wrapper will be sufficient.
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
No, calling it a jihad is a little bit of an exaggeration for one thing. And for another, if it is a holy war, it's against the failure to disclose technical specifications that would allow kernel developers to write and maintain their own driver code for the hardware.
(*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.
Acting against the interests of the users? Hardly. The best possible result for the users would be that nVidia releases their specs to the public, causing their development team to suddenly increase from a handful to hundreds or thousands. Considering that nVidia is now in the process of getting hammered by ATI (who is, coincidentally, more open with tech specs) perhaps they should reflect on the wisdon of doing just that. At the very least, they'd increase their sales to Linux users dramatically, and trust me, that is no longer small change. "Earth to nVidia".
If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.
Linux is already mainstream, or perhaps you do not think that 20 million users is mainstream.
Perhaps you meant 'dominant', in which case you would be even more wrong, because when Linux does become dominant, companies will have even more reason to go with the flow and release their kernel modules in source form. Note that they will still be, and always have been, free to release their applications in closed, binary form.
Note also, that companies doing the right thing and releasing their drivers in source form is always better for the user because such code is more likely to operate reliably and won't fall into hopeless disrepair if the original vendor dies.
Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver
The module interface itself doesn't change often (though it happens to be going through a big change right now, it's the first in a long while). The calls that support normal Unix programs hardly ever change either, which you can verify for yourself by checking running an old application that links to, say, libc5. It still works, even with recent Linux kernels. If there are changes to the interface between libc and the kernel, they are nearly always additions, to add 64 bit versions of file operations, for example.
What do change regularly are the internal kernel apis, and this is always to make them better, for some definition of better: faster, easier to use, more capable, more reliable, easier to understand, better error handling, etc. Breakage of binary modules is invariably due to them relying on those internal kernel interfaces.[1] But it is exactly this willingness to change the kernel internals at a moment's notice[2] that keeps Linux evolving and improving so fast. That's already plenty of reason for doing it, and if it also provides gentle encouragement to people to share their code with the public, so much the better.
[1] But for modules provided in source form, the kernel developers will happily do the work of updating them to reflect kernel api changes. Often, there will be no changes at all required to modules in source form, because api changes can be hidden behind macros etc.
[2] Even within the kernel, such changes are normally only made in the development kernel series, so that even internal apis stay stable through each stable kernel cycle, i.e., about two years.
It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system.
No, it's not. There is no restriction whatsoever in running any kind of application you want under Linux. Did you ignore the distinction between kernel and user mode intentionally?
It's more like Microsoft changing the Windows license to disallow any GPL code in the Windows kernel. Oh wait...
The vast majority of illegal aliens in the US are migrant workers from Mexico. Following Mexico are El Salvador, Guatamala and Canada.
Migrant workers from Canada? You must be joking. Perhaps you are thinking of retired Torontonians living in Florida, collectively known as "snowbirds".
Wow, Linux is being used in a product that Windows isn't even targeted towards. I don't think that Microsoft cares too much if linux is used in these types of devices. Especially when they still own 95% of the desktop market.
Oh, Microsoft caresall right. But they are fighting an uphill battle against free-and-open in that space. MS has lost a lot of ground to Linux there, is continuing to lose more, and there's really no hope of a comeback.
Actually, those componentized versions of windows were very much the right idea, and Microsoft had an advantage there for a while.
Real already knows my genenetic code they have so much junk watching me when I install Real software with default options. They've probably figured out a way to have my monitor probe my brain.
Paranoia? I don't think so...
I know that was supposed to come across as funny, but it also - I think intentionally - misses the point. This is a source distribution, it will not have spyware. If it did, you'd just remove it, wouldn't you? Or move on to another project, so it's a safe bet Realnetworks won't do that.
It [flat real mode] can be very useful in getting a 32-bit protected mode operating system running. This is because as soon as you switch to protected mode, you need to write all of your own interrupt code (i.e. if you've ever written code in x86 assembly under DOS, you have access to a ton of INT(errupt) instructions that do things like write to the screen, read from a disk, etc, but in Pmode, YOU must write the code to do all of this yourself - quite tedious and time-consuming).
Sorry, that's inaccurate. For a basic Dos extender you just had to:
- Set up the GDT and IDT
- Point the 32 bit interrupts at the 16 bit real
mode interrupts
- Write special case code for interrupts that use pointers, such as disk io, to copy the data
via a buffer instead
- A few other wrinkles
It took me 2-3 weeks to do that as I recall. There was no rewriting of bios routines needed, though since most of them suck too badly for words, it's worth doing anyway.
I did not find 32 bit protected mode to be significantly slower than real mode.
Well, in unreal mode, you switch to pmode, then switch back to real mode without resetting the segment registers, and gain access to the entire 32-bit flat address space, and still use the real mode interrupts.
And try to handle all the grotty little cases where an interrupt or something comes along and destroys the internal registers. 32 bit real mode was a bad idea, no two ways about it, and a really bad strategy for writing a game.
I used Quickbooks a *long* time ago to help out with my father's small business. For myself, I've been using GNUcash
I last looked at Gnucash about three years ago, and at the time I found it:
- Tricky to install, with lots of dependencies
- Pretty rough user inteface
but, and this is the important thing, under active development. Just now I did apt-get install gnucash, and two minutes later I'm in the tutorial. Wow, big difference. The interface is GTK, which in my experience tends to imply slower project progress on the gui front, but leaves you with much shorter startup times and snappier response, compared to the same thing in QT/KDE, and runs fine under KDE, which suits me just fine.
The new user manual is a work in progress, but the parts that are done are really nice to look at, loaded with screen shots just like a commercial product. But of course, not loaded with nags and advertisements, unlike a commercial product.
I didn't go deeper than taking a quick look at the docs, but my impression from what I've heard people say about it is, it's usable. That's good enough for me. Once any OSS project gets to "usable", you know it's just going to keep getting better from there. Plus, this is the kind of code I like to build from source and do a little hacking on. I suppose that if somebody hasn't already done it by the time I need it, making a nice interface for printing cheques would be fun. What I'd be thinking in terms of is:
One-time setup:
- Scan in the blank cheques so they can be usedas wallpaper for a print preview
- Switch to a forms view of the cheque table with the scanned cheques as the wallpaper.
- Drag the amount field etc into proper position against the wallpaper
Now, to do a print a cheque run:
- First, get the whole cheque run into a table view, so you can see all the cheques and the
effects on account balances
- Now flip to the forms view with the cheque wallpaper. You should be able to page up/down
to see each cheque that's going to be printed
- Load the cheques in the printer and go
- In case of something mis-printed, you need to be able to cancel the obliterated cheques in
the database as "spoiled" and issue new ones, with new numbers but otherwise identical. This
happens all the time, so it has to be efficient to get back on track here. Of course, the accounts
have to be seen to be correct after all this!
So, the idea it's all wysiwyg, which is just the space I like to be in when I'm doing something as dull as accounting. I.e., I'd rather spend a week coding up a drool-mindless easy interface, once, than waste a minute or two fiddling around with a crude interface every time, especially the first time, trying to get the fields in the right places.
Anyway, crude cheque printing or not, this package looks like it's ready for real work.
time gcc-2.95 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m3.058s user 0m2.680s sys 0m0.060s
time gcc-3.2 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m5.991s user 0m4.620s sys 0m0.050s
i.e., tinycc does the job 6 times faster than gcc 2.95 does, and 12 times faster than 3.2. The tcc-compiled tcc takes 45% more time to compile itself than the gcc-compile version:
time bin-tcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m0.521s user 0m0.460s sys 0m0.000s
time bin-gcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m0.360s user 0m0.280s sys 0m0.030s
Note: there's 4-5% variation in the various timings due to cache effects.
Thanks for that. I grabbed the source, which fails to build (on linux) with:
tccelf.c:382: `RTLD_DEFAULT' undeclared
Supplying the missing definition gets it to build, then I was able to get it to self-compile just by supplying a -I to the gcc headers and a symlink to the build directory for the libraries (I like it when I can evade sudo make install easily). Yes, it's instantaneous.
It's a recursive-descent one-pass compiler, i.e., inline code generation, as you might expect. There's little or no register optimization and no discernable global optimization, again as you might expect, so it's a slight exaggeration to say it generates code quality near the level of gcc -O2. The compile speed would way more than make up for this in the vast majority of development situations.
Without inline assembly or support for gcc's weird array of special attributes, you couldn't compile much of the kernel with this, but maybe with a little tweaking you could compile module code.
I'd like to see somebody take on the challenge of a tiny two-pass C compiler, with an intermediate parse tree. How much bigger would it be? Not much, and the extra time to build+traverse the tree would likely only add 20-30% to compile time, leaving it still several times faster than gcc (ever more so vs gcc 3.x). This design would open up the field for 'tiny global optimization', which would be fun to see.
the semicolons between statements are completely optional, so you can write a:=1; b:=2 or a:=1 b:=2. This does not make the language ambiguous, but it means that you can only catch very few syntax errors at a time (usually, parsers can skip erroneous statements and report syntax errors even after them).
The usefulness of this is highly overrated. It harkens back to the days when programs were punched on paper card decks and you had to stand in line to submit your compile. You'd better catch as many syntax errors on each run as possible, for sure. But when you have fast compiler turnaround and tight integration to an editor, the equation shifts strongly in favor of one-at-a-time error correction. Simply put, the cursor should land on the first error, which you can typically correct in a few keystrokes, and resubmit. Your eyes never leave the source file.
This way of working is a *lot* faster than sifting through lists of error messages, where many errors often cascade off an early one. The time you spend analyzing such dependencies is 100% wasted. It's also annoying to have to keep shifting your eyes between the source code and the lists of error messages. Anyone who can keep concentrating on the original problem (i.e., not the syntax errors) while doing this is a freak mutant alien.
The compiler we used to work with (ISE's Eiffel Bench) actually reported only one error at a time which was at some random place in the code. Just imagine the experience of writing a bigger piece and then trying to compile it.
Ehh? I have worked on huge programs with one-at-a-time error messages, I don't have to imagine it. It's a far more efficient way to work, regardless of project size. It does depend on tight integration with the editor though, which for some inexplicable reason, is still not treated as a high priority by most developers.
The ideal system would always give you the first error in tight-editor-integration mode, and continue looking for more in the background while you are busy editing. That's what excess cpu cycles are for, right? On the rare occasion you're interested in more than one at a time, you can look at the full list.
In language design, we've pretty much settled on C syntax for executable code. No new language with non-C executable syntax has gone very far in the last 15 years or so. Python acceptance is held back by its indentation/no semicolon style, even though it has many good ideas.
I'd call that wishful thinking. My unscientific observations suggest Python continues to grow exponentially, and there is Basic (not all dialects are as broken as VB) which still has a huge mindshare. Actually, a quick look into my crystal ball shows me fewer semicolons in the future, not more.
Re:Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 2
Re:Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 2
Have you even tried getting on the phone and calling their documentation department?
Yes. As I mentioned in my post, they just asked for a product serial number and it went no further.
In the past I've found no register level docs on the web site, but was able to get paper copies w/o much hassle by calling them and ordering it.
Sorry, that's just not good enough, especially considering the above brick wall. If they want their chip properly supported, they should just post the the docs on their web site.
The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty.
Most vendors give a binary blob to load onto the card for the on-board sequencer.
Many other vendors have similar or worse mental deficiencies, it's true, however there's no safety in numbers here. There used to be lots of dodos as well.
In short, I don't think that you have the first clue what you are talking about here.
Re:Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 2
LOL! Google doesn't offer much proof. Your very search query is flawed.
"nvidia tainted [bug]" also gets reports of "not tainted" kernels with lspci output containing nVidia. Not to mention leaving out other bug-inducing items like patched kernels.
Look, this is well known. NVidia's driver does memory managment, takes various locks and such. It is sensitive to changes in the core kernel. If NVidia provided the driver in source form, Linux developers would keep the thing maintained, but they don't, so it keeps breaking.
Try real research next time buddy.
Trying pulling hard, and that foot may suddenly pop out of your mouth.
Re:Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 2
"This is a far better performance than, for example, NVidia, whose drivers are well-known for breaking every few kernel releases because of their binary-only nature."
Stop spreading your FUD here. This claim is totally unsubstantiated. I've been using the nVidia driver with the latest stable kernels for a long time now with no problems.
Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 4, Insightful
I have a similar problem with Adaptec. I'm trying to get register-level specs for their AIC-7xxx series of scsi chips. On their Linux page they claim to support open source:
We have launched a dedicated Web site to provide a repository of
information for our open source solutions, including:
* Our latest Open Source drivers
* Technical documentation
* White papers
* FAQs
But in fact there is no technical documentation available beyond lightweight lists lists of features and general hardware type. Directly contacting Adaptec, I get nowhere without a product serial number, which of course I don't have because the chips are embedded in an OEM motherboard.
So maybe I'm just not talking to the right person, but it does look like the company is saying one thing and doing another.
To be fair, the driver support for Linux is good. Drivers are developed by an Adaptec-sponsored group and provided in source form. These drivers are in the mainline 2.4 and 2.5 source trees. This is a far better performance than, for example, NVidia, whose drivers are well-known for breaking every few kernel releases because of their binary-only nature. Still, it's not enough. It seems to me Adaptec is just shooting themselves in the foot by keeping the low level interface specs closed. If they continue to do that, they will certainly be knocked out of the market by other hardware that's better understood by kernel hackers, for which both low and high level optimization can be done by lots of developers. That's exactly what I'm trying to do with their chips, and to be frank, I'm doing it only because I happen to have one available to play with at the moment. But I'll move on without hesitation as soon as something shows up that gives me more scope for interesting optimizations. I'm just not one of those people who enjoys reverse-engineering, though I have immense respect for those who do.
The way things are, the Adaptec guys who develop the Linux drivers can do plenty of low level optimization based on things that only they know about the hardware, but who will listen to them if they want changes in the core kernel for better support? Plus, who wants to invest in hardware that is certain to become unsupportable as soon as the company EOLs the product? With Linux basically taking over the server market, I see that policy as the most efficient way to become part of the sedimentary fossil record as soon as possible.
Slashdot Mirror
The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.
Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.
Dynamic linking is treated the same as static linking, which is why the LGPL exists.
How about you go branch your own Linux kernel tree and add code back in that better supports binary-only modules?
Well, he'd have to be careful there, since some copyright holders might take issue if the changes amounted to a relicensing, but sure, he could maintain his own tree if he liked, and never change it so that binary modules never break. Of course it would never get better either...
"This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task."
What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.
Err. Many (or perhaps even most) companies have already made major investments in Linux. And your point is?
If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible..
They are not. If the modem driver already runs under a wrapper, then updating the wrapper will be sufficient.
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
No, calling it a jihad is a little bit of an exaggeration for one thing. And for another, if it is a holy war, it's against the failure to disclose technical specifications that would allow kernel developers to write and maintain their own driver code for the hardware.
(*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.
Acting against the interests of the users? Hardly. The best possible result for the users would be that nVidia releases their specs to the public, causing their development team to suddenly increase from a handful to hundreds or thousands. Considering that nVidia is now in the process of getting hammered by ATI (who is, coincidentally, more open with tech specs) perhaps they should reflect on the wisdon of doing just that. At the very least, they'd increase their sales to Linux users dramatically, and trust me, that is no longer small change. "Earth to nVidia".
If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.
Linux is already mainstream, or perhaps you do not think that 20 million users is mainstream.
Perhaps you meant 'dominant', in which case you would be even more wrong, because when Linux does become dominant, companies will have even more reason to go with the flow and release their kernel modules in source form. Note that they will still be, and always have been, free to release their applications in closed, binary form.
Note also, that companies doing the right thing and releasing their drivers in source form is always better for the user because such code is more likely to operate reliably and won't fall into hopeless disrepair if the original vendor dies.
Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver
The module interface itself doesn't change often (though it happens to be going through a big change right now, it's the first in a long while). The calls that support normal Unix programs hardly ever change either, which you can verify for yourself by checking running an old application that links to, say, libc5. It still works, even with recent Linux kernels. If there are changes to the interface between libc and the kernel, they are nearly always additions, to add 64 bit versions of file operations, for example.
What do change regularly are the internal kernel apis, and this is always to make them better, for some definition of better: faster, easier to use, more capable, more reliable, easier to understand, better error handling, etc. Breakage of binary modules is invariably due to them relying on those internal kernel interfaces.[1] But it is exactly this willingness to change the kernel internals at a moment's notice[2] that keeps Linux evolving and improving so fast. That's already plenty of reason for doing it, and if it also provides gentle encouragement to people to share their code with the public, so much the better.
[1] But for modules provided in source form, the kernel developers will happily do the work of updating them to reflect kernel api changes. Often, there will be no changes at all required to modules in source form, because api changes can be hidden behind macros etc.
[2] Even within the kernel, such changes are normally only made in the development kernel series, so that even internal apis stay stable through each stable kernel cycle, i.e., about two years.
"Microsoft are busy working on just this and it's much worse than you would imagine."
No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.
You don't know that.
It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system.
No, it's not. There is no restriction whatsoever in running any kind of application you want under Linux. Did you ignore the distinction between kernel and user mode intentionally?
It's more like Microsoft changing the Windows license to disallow any GPL code in the Windows kernel. Oh wait...
The vast majority of illegal aliens in the US are migrant workers from Mexico. Following Mexico are El Salvador, Guatamala and Canada.
Migrant workers from Canada? You must be joking. Perhaps you are thinking of retired Torontonians living in Florida, collectively known as "snowbirds".
Here's a sound engine [libsdl.org].
Actually, for sound you'd want OpenAL. This works together with SDL but isn't tied to it.
Wow, Linux is being used in a product that Windows isn't even targeted towards. I don't think that Microsoft cares too much if linux is used in these types of devices. Especially when they still own 95% of the desktop market.
Oh, Microsoft cares all right. But they are fighting an uphill battle against free-and-open in that space. MS has lost a lot of ground to Linux there, is continuing to lose more, and there's really no hope of a comeback.
Actually, those componentized versions of windows were very much the right idea, and Microsoft had an advantage there for a while.
Real already knows my genenetic code they have so much junk watching me when I install Real software with default options. They've probably figured out a way to have my monitor probe my brain.
Paranoia? I don't think so...
I know that was supposed to come across as funny, but it also - I think intentionally - misses the point. This is a source distribution, it will not have spyware. If it did, you'd just remove it, wouldn't you? Or move on to another project, so it's a safe bet Realnetworks won't do that.
It [flat real mode] can be very useful in getting a 32-bit protected mode operating system running. This is because as soon as you switch to protected mode, you need to write all of your own interrupt code (i.e. if you've ever written code in x86 assembly under DOS, you have access to a ton of INT(errupt) instructions that do things like write to the screen, read from a disk, etc, but in Pmode, YOU must write the code to do all of this yourself - quite tedious and time-consuming).
Sorry, that's inaccurate. For a basic Dos extender you just had to:
- Set up the GDT and IDT
- Point the 32 bit interrupts at the 16 bit real
mode interrupts
- Write special case code for interrupts that use pointers, such as disk io, to copy the data
via a buffer instead
- A few other wrinkles
It took me 2-3 weeks to do that as I recall. There was no rewriting of bios routines needed, though since most of them suck too badly for words, it's worth doing anyway.
I did not find 32 bit protected mode to be significantly slower than real mode.
Well, in unreal mode, you switch to pmode, then switch back to real mode without resetting the segment registers, and gain access to the entire 32-bit flat address space, and still use the real mode interrupts.
And try to handle all the grotty little cases where an interrupt or something comes along and destroys the internal registers. 32 bit real mode was a bad idea, no two ways about it, and a really bad strategy for writing a game.
I used Quickbooks a *long* time ago to help out with my father's small business. For myself, I've been using GNUcash
I last looked at Gnucash about three years ago, and at the time I found it:
- Tricky to install, with lots of dependencies
- Pretty rough user inteface
but, and this is the important thing, under active development. Just now I did apt-get install gnucash, and two minutes later I'm in the tutorial. Wow, big difference. The interface is GTK, which in my experience tends to imply slower project progress on the gui front, but leaves you with much shorter startup times and snappier response, compared to the same thing in QT/KDE, and runs fine under KDE, which suits me just fine.
The new user manual is a work in progress, but the parts that are done are really nice to look at, loaded with screen shots just like a commercial product. But of course, not loaded with nags and advertisements, unlike a commercial product.
I didn't go deeper than taking a quick look at the docs, but my impression from what I've heard people say about it is, it's usable. That's good enough for me. Once any OSS project gets to "usable", you know it's just going to keep getting better from there. Plus, this is the kind of code I like to build from source and do a little hacking on. I suppose that if somebody hasn't already done it by the time I need it, making a nice interface for printing cheques would be fun. What I'd be thinking in terms of is:
One-time setup:
- Scan in the blank cheques so they can be usedas wallpaper for a print preview
- Switch to a forms view of the cheque table with the scanned cheques as the wallpaper.
- Drag the amount field etc into proper position against the wallpaper
Now, to do a print a cheque run:
- First, get the whole cheque run into a table view, so you can see all the cheques and the
effects on account balances
- Now flip to the forms view with the cheque wallpaper. You should be able to page up/down
to see each cheque that's going to be printed
- Load the cheques in the printer and go
- In case of something mis-printed, you need to be able to cancel the obliterated cheques in
the database as "spoiled" and issue new ones, with new numbers but otherwise identical. This
happens all the time, so it has to be efficient to get back on track here. Of course, the accounts
have to be seen to be correct after all this!
So, the idea it's all wysiwyg, which is just the space I like to be in when I'm doing something as dull as accounting. I.e., I'd rather spend a week coding up a drool-mindless easy interface, once, than waste a minute or two fiddling around with a crude interface every time, especially the first time, trying to get the fields in the right places.
Anyway, crude cheque printing or not, this package looks like it's ready for real work.
Oh, to be fair:
time gcc-2.95 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m3.058s
user 0m2.680s
sys 0m0.060s
time gcc-3.2 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m5.991s
user 0m4.620s
sys 0m0.050s
i.e., tinycc does the job 6 times faster than gcc 2.95 does, and 12 times faster than 3.2. The tcc-compiled tcc takes 45% more time to compile itself than the gcc-compile version:
time bin-tcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m0.521s
user 0m0.460s
sys 0m0.000s
time bin-gcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl
real 0m0.360s
user 0m0.280s
sys 0m0.030s
Note: there's 4-5% variation in the various timings due to cache effects.
try using TinyCC [tinycc.org] instead of GCC.
Thanks for that. I grabbed the source, which fails to build (on linux) with:
tccelf.c:382: `RTLD_DEFAULT' undeclared
Supplying the missing definition gets it to build, then I was able to get it to self-compile just by supplying a -I to the gcc headers and a symlink to the build directory for the libraries (I like it when I can evade sudo make install easily). Yes, it's instantaneous.
It's a recursive-descent one-pass compiler, i.e., inline code generation, as you might expect. There's little or no register optimization and no discernable global optimization, again as you might expect, so it's a slight exaggeration to say it generates code quality near the level of gcc -O2. The compile speed would way more than make up for this in the vast majority of development situations.
Without inline assembly or support for gcc's weird array of special attributes, you couldn't compile much of the kernel with this, but maybe with a little tweaking you could compile module code.
I'd like to see somebody take on the challenge of a tiny two-pass C compiler, with an intermediate parse tree. How much bigger would it be? Not much, and the extra time to build+traverse the tree would likely only add 20-30% to compile time, leaving it still several times faster than gcc (ever more so vs gcc 3.x). This design would open up the field for 'tiny global optimization', which would be fun to see.
time gcc -O2 -g -Wall -m386 -malign-functions=0 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc_g tcc.c -ldl
real 0m8.833s
user 0m8.120s
sys 0m0.140s
time bin/tcc_g -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc_g tcc.c -ldl
real 0m0.502s
user 0m0.430s
sys 0m0.040s
the semicolons between statements are completely optional, so you can write a:=1; b:=2 or a:=1 b:=2. This does not make the language ambiguous, but it means that you can only catch very few syntax errors at a time (usually, parsers can skip erroneous statements and report syntax errors even after them).
The usefulness of this is highly overrated. It harkens back to the days when programs were punched on paper card decks and you had to stand in line to submit your compile. You'd better catch as many syntax errors on each run as possible, for sure. But when you have fast compiler turnaround and tight integration to an editor, the equation shifts strongly in favor of one-at-a-time error correction. Simply put, the cursor should land on the first error, which you can typically correct in a few keystrokes, and resubmit. Your eyes never leave the source file.
This way of working is a *lot* faster than sifting through lists of error messages, where many errors often cascade off an early one. The time you spend analyzing such dependencies is 100% wasted. It's also annoying to have to keep shifting your eyes between the source code and the lists of error messages. Anyone who can keep concentrating on the original problem (i.e., not the syntax errors) while doing this is a freak mutant alien.
The compiler we used to work with (ISE's Eiffel Bench) actually reported only one error at a time which was at some random place in the code. Just imagine the experience of writing a bigger piece and then trying to compile it.
Ehh? I have worked on huge programs with one-at-a-time error messages, I don't have to imagine it. It's a far more efficient way to work, regardless of project size. It does depend on tight integration with the editor though, which for some inexplicable reason, is still not treated as a high priority by most developers.
The ideal system would always give you the first error in tight-editor-integration mode, and continue looking for more in the background while you are busy editing. That's what excess cpu cycles are for, right? On the rare occasion you're interested in more than one at a time, you can look at the full list.
In language design, we've pretty much settled on C syntax for executable code. No new language with non-C executable syntax has gone very far in the last 15 years or so. Python acceptance is held back by its indentation/no semicolon style, even though it has many good ideas.
I'd call that wishful thinking. My unscientific observations suggest Python continues to grow exponentially, and there is Basic (not all dialects are as broken as VB) which still has a huge mindshare. Actually, a quick look into my crystal ball shows me fewer semicolons in the future, not more.
Really, try real research, not this google crap.
Since you asked so nicely...
Have you even tried getting on the phone and calling their documentation department?
Yes. As I mentioned in my post, they just asked for a product serial number and it went no further.
In the past I've found no register level docs on the web site, but was able to get paper copies w/o much hassle by calling them and ordering it.
Sorry, that's just not good enough, especially considering the above brick wall. If they want their chip properly supported, they should just post the the docs on their web site.
The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty.
Most vendors give a binary blob to load onto the card for the on-board sequencer.
Many other vendors have similar or worse mental deficiencies, it's true, however there's no safety in numbers here. There used to be lots of dodos as well.
In short, I don't think that you have the first clue what you are talking about here.
Give me a break. Go look for yourself.
LOL! Google doesn't offer much proof. Your very search query is flawed.
"nvidia tainted [bug]" also gets reports of "not tainted" kernels with lspci output containing nVidia. Not to mention leaving out other bug-inducing items like patched kernels.
Right:
If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get a
kernel BUG at filemap.c:236 in...
Look, this is well known. NVidia's driver does memory managment, takes various locks and such. It is sensitive to changes in the core kernel. If NVidia provided the driver in source form, Linux developers would keep the thing maintained, but they don't, so it keeps breaking.
Try real research next time buddy.
Trying pulling hard, and that foot may suddenly pop out of your mouth.
"This is a far better performance than, for example, NVidia, whose drivers are well-known for breaking every few kernel releases because of their binary-only nature."
Stop spreading your FUD here. This claim is totally unsubstantiated. I've been using the nVidia driver with the latest stable kernels for a long time now with no problems.
Substantiation.
I have a similar problem with Adaptec. I'm trying to get register-level specs for their AIC-7xxx series of scsi chips.
On their Linux page they claim to support open source:
We have launched a dedicated Web site to provide a repository of
information for our open source solutions, including:
* Our latest Open Source drivers
* Technical documentation
* White papers
* FAQs
But in fact there is no technical documentation available beyond lightweight lists lists of features and general hardware type. Directly contacting Adaptec, I get nowhere without a product serial number, which of course I don't have because the chips are embedded in an OEM motherboard.
So maybe I'm just not talking to the right person, but it does look like the company is saying one thing and doing another.
To be fair, the driver support for Linux is good. Drivers are developed by an Adaptec-sponsored group and provided in source form. These drivers are in the mainline 2.4 and 2.5 source trees. This is a far better performance than, for example, NVidia, whose drivers are well-known for breaking every few kernel releases because of their binary-only nature. Still, it's not enough. It seems to me Adaptec is just shooting themselves in the foot by keeping the low level interface specs closed. If they continue to do that, they will certainly be knocked out of the market by other hardware that's better understood by kernel hackers, for which both low and high level optimization can be done by lots of developers. That's exactly what I'm trying to do with their chips, and to be frank, I'm doing it only because I happen to have one available to play with at the moment. But I'll move on without hesitation as soon as something shows up that gives me more scope for interesting optimizations. I'm just not one of those people who enjoys reverse-engineering, though I have immense respect for those who do.
The way things are, the Adaptec guys who develop the Linux drivers can do plenty of low level optimization based on things that only they know about the hardware, but who will listen to them if they want changes in the core kernel for better support? Plus, who wants to invest in hardware that is certain to become unsupportable as soon as the company EOLs the product? With Linux basically taking over the server market, I see that policy as the most efficient way to become part of the sedimentary fossil record as soon as possible.
Something very odd about the single-drive ATA 100 results here. Anybody have a theory? To me, it looks as though the test is broken.