Free Pascal's development version is just a bit too short of compiling the D5 VCL tree. But it won't take long anymore. If Kylix (as far as language is concerned) isn't too different from D5, we can have fun:-)
Most of the remaining incompabilities are in the unicode regions (and their support in variants)
I mailed GNU about this, and according to RMS.DLLs don't count as shared libraries, since you can obtain the adress and call it directly.
I asked this because this complicates having commercial DLL plugins to a GPL program.
The answer is no, only commercial DLLs that come with the OS are allowed.
The BSD-license zealots will try to twist this question in a pro-BSD statement. Don't forget that a BSD license means that a company can take your package, start developping it commercially, put some FTE's on it and rob you from all your users,
(they send them patches and bugreports), make it uninteresting for your sponsors etc.
Not always that likely, but surely something to be kept in mind. (And I say this as a BSDer)
Then why do you expect to get a free ride from the open-source community if you have nothing to add?
Simply pay up for commercial tools, and shut up.
You do
yourself (get it instantly with support),
the open-source community (one whiner with nothing to add less). Open source is a give and take thing
And the people writing commercial developper software get food on the table too (they have actual jobs and develop for a living), that way, a decent developper firm (like Borland) doesn't have to be supported by Microsoft.
a favour.
(P.s. what is that VB people keep trying to tell me about?
P.p.s. I do write a lot of code. But I keep hobby and profession strictly separated, and for professional work, I pay my dues for professional software, and for my non-commercial stuff I do actual work myself, and contribute back to the community, instead of doubling the workload of hard working core-teams with my whining)
Actually I do program, and a reasonably large project, and that project (though not me) partially patches GDB, because GDB lacked Pascal support. So I didn't cite some Open Source manual, I experienced it from pretty nearby.
Besides, you are missing the point, besides hacking full GDB threading support, he could have made a small patch that would allow him to easier track the thread context. Or he could change the threading libraries to extract more information, which he could check while debugging.
But the main point is, to be creative either in a minimal way, or a major one (read the full threading support), rather than whine about something people have put in a lot of effort.
I wouldn't push the kid too far. I myself was also an assembler programmer at the time, and do some open source work and other programming now, but I might well have given up in puberty as well.
Don't let him waste too many years, or push him too easy in a direction he might see in a different perspective in a few years.
But the answer:
Standard programming. Let him program small games in standard languages (Pascal(Delphi or one of the free ones, TP is too old) , Basic (not necessarily VB), C, C++). Thinks like Tetris, Seawars, Columns, Chainreaction, whatever.
For the OS part, let take Tanenbaum's book about Minix. Study small OSes, or flat-real experiments
Don't throw him in pure (protected mode, OS kernel related) assembler yet. Let him optimize some of his HLL code by searching the limiting procedures, and rewriting them in assembler first. Knowing what to do in assembler, and the idea you get how HLL's work by reviewing their disassembled output is more important than trying to write a new OS in assembler.
Let him create a simple shell program in DOS. A mini-bash, a mini GUI, a mini textwindowing interface. Good for lowlevel and for code reuse, parsing input
Expression parser/ mini scripting engine.
I'm no CS starters teacher, some people are, why don't you check their material.
In general, forget about the busswords of the moment, since when he is getting good, they will have changed (think XML, Java,.NET, maybe even Perl. Personally I think XML and Perl are here to stay, but if he knows real languages, he can deal easily with those too
I think that too. The company would have actually answered the question (and said something about threading, which is totally absent in the Paradigm post)
The few lowlevel workarounds that are included (single handedly setting cs:ip), can be done in GDB too afaik.
Read: NOTHING will change.
If the core team that gets their hands on BeOS is
flexible, BeOS will be bent to get Unix (and even Windows) applications better ported. Some projects to create new interface classes will startup (and fade after half an year as usual).
If the people that become the BeOS core team are purists, BeOS will fade.
Case closed:-)
Well, I think that there is also a very substantial pricefall that is going to occur in the 3D market, so this doesn't necessarily mean higher prices.
Also NVidia until know still has delivered quality products for a reasonal price. Monopolies are rarely healthy though.
Pretty nice 3D graphic cards are going to get integrated into the chipset, further lowering prices of a decent system. (for the people that aren't hardcore gamers, or don't do 3D shooters)
Expensive support is available from various companies for Linux and Windows.
With cheap support for Windows you have a problem. Half the time you find a fix on the Microsoft page, but it isn't "fully regression tested" so you get nothing. The last service pack from NT is already nearly a year old (though I saw some "presp7" tags in some kb articles a few weeks back)
With linux you will have to wait from time
to time with the smaller problems, but really annoying stuff you could either try to fix yourself, or hire somebody who can on *per incident* basis
Also instead of the waiting for RedHat/SUSE/whatever-fix, you also have to possibility to alert the community directly, and speed up the process of getting it fixed.
Well, since I'm the first, lets speak out the obvious:
I think that it is shame that a magazine of the scientific standing like Science and Nature take a stand in such debated terrain as patents on genomes.
As authorothies in science-land they should at least keep up the *appearance* of impartiality.
Slashdot Mirror
And of course the fact that a true hacker wouldn't use KDE, even if his life (kernel) depended on it :-)
Free market is used for things that are scarse by nature.
Privacy (in this context) is not one of those. It is not a God given right for companies to collect data about the public.
So: Absolutely ridiculous.
Free Pascal's development version is just a bit too short of compiling the D5 VCL tree. But it won't take long anymore. If Kylix (as far as language is concerned) isn't too different from D5, we can have fun
Most of the remaining incompabilities are in the unicode regions (and their support in variants)
The odd part is that RH will already be preparing, and simply provide a post-update RPM on June 1st, without any major release inbetween.
I mailed GNU about this, and according to RMS .DLLs don't count as shared libraries, since you can obtain the adress and call it directly.
I asked this because this complicates having commercial DLL plugins to a GPL program.
The answer is no, only commercial DLLs that come with the OS are allowed.
The BSD-license zealots will try to twist this question in a pro-BSD statement. Don't forget that a BSD license means that a company can take your package, start developping it commercially, put some FTE's on it and rob you from all your users,
(they send them patches and bugreports), make it uninteresting for your sponsors etc.
Not always that likely, but surely something to be kept in mind. (And I say this as a BSDer)
Ther register already had a story about how to break it a few days back.
You can simply start regedit at some point during installation and exit.
Anyway, it only bothers home users, real pirates will hack and workaround it in no time, which is why it is an idiotic idea.
I heard Dutch provider xs4all blocks ranges from the Chello (=UPC) cable company.
I think that you confuse OOP with modularisation here.
You can do that in a procedural language too, it isn't an OOP feature.
You have to think in modularisation that you can do with OOP, but not (in the same magnitude of difficulaty) with procedural langauges.
IOW direct benefits from the polymorphism and inhertance, not purely from writing modularised.
Employing people on large Open Source (FreeBSD,Linux,GNU) projects, open up sources.
And as long as you don't switch OS, plan to use out of the ordinary (like 2.5 soon) kernel versions, and don't try to fit it into an Alpha or Mac.
That one doesn't support MX cards, and only works under Linux/i386 (not other systems running XFree)
No, but OpenBSD is bent the Unix way, you have to admit that ;-)
But enlighten me, what would be (long-term, compared with developping Gnome, KDE and Mac OS/X) be the grand improvements for BeOS?
Most that can afford it, inherited it from their parents.
Nothing Darwin about that.
Simply pay up for commercial tools, and shut up. You do
- yourself (get it instantly with support),
- the open-source community (one whiner with nothing to add less). Open source is a give and take thing
- And the people writing commercial developper software get food on the table too (they have actual jobs and develop for a living), that way, a decent developper firm (like Borland) doesn't have to be supported by Microsoft.
a favour.(P.s. what is that VB people keep trying to tell me about?
P.p.s. I do write a lot of code. But I keep hobby and profession strictly separated, and for professional work, I pay my dues for professional software, and for my non-commercial stuff I do actual work myself, and contribute back to the community, instead of doubling the workload of hard working core-teams with my whining)
Actually I do program, and a reasonably large project, and that project (though not me) partially patches GDB, because GDB lacked Pascal support. So I didn't cite some Open Source manual, I experienced it from pretty nearby.
Besides, you are missing the point, besides hacking full GDB threading support, he could have made a small patch that would allow him to easier track the thread context. Or he could change the threading libraries to extract more information, which he could check while debugging.
But the main point is, to be creative either in a minimal way, or a major one (read the full threading support), rather than whine about something people have put in a lot of effort.
And BTW I don't want GC in C.
How did he get a huge MT app without a debugger? I think that that app is the thing that is overrated then :-)
Don't let him waste too many years, or push him too easy in a direction he might see in a different perspective in a few years.
But the answer:
In the true open source mind, it would be better to say:
You are changing a debugger because it misses a feature? THEN IMPLEMENT IT
I'm sure the GDB team is curiously awaiting your patches.
You can CVS the GDB source up to date every day.
(I use a gdb from the devel branch, because it compiles easier on FreeBSD)
I think that is a pretty severe performance hit.
I would rather use the Ada as suggested before.
I think that too. The company would have actually answered the question (and said something about threading, which is totally absent in the Paradigm post)
The few lowlevel workarounds that are included (single handedly setting cs:ip), can be done in GDB too afaik.
Read: NOTHING will change. If the core team that gets their hands on BeOS is flexible, BeOS will be bent to get Unix (and even Windows) applications better ported. Some projects to create new interface classes will startup (and fade after half an year as usual). If the people that become the BeOS core team are purists, BeOS will fade. Case closed :-)
Well, I think that there is also a very substantial pricefall that is going to occur in the 3D market, so this doesn't necessarily mean higher prices.
Also NVidia until know still has delivered quality products for a reasonal price. Monopolies are rarely healthy though.
Pretty nice 3D graphic cards are going to get integrated into the chipset, further lowering prices of a decent system. (for the people that aren't hardcore gamers, or don't do 3D shooters)
Just checked, NetBSD still doesn't support the Performa x200 series. (the "rotten" apples).
Pity, I bought two for a good bottle of wine
Anyway, back to Linux then. At least Mklinux (www.mklinux.org) seems to have working beta versions of a kernel for these machines.
-
Expensive support is available from various companies for Linux and Windows.
- With cheap support for Windows you have a problem. Half the time you find a fix on the Microsoft page, but it isn't "fully regression tested" so you get nothing. The last service pack from NT is already nearly a year old (though I saw some "presp7" tags in some kb articles a few weeks back)
- With linux you will have to wait from time
to time with the smaller problems, but really annoying stuff you could either try to fix yourself, or hire somebody who can on *per incident* basis
- Also instead of the waiting for RedHat/SUSE/whatever-fix, you also have to possibility to alert the community directly, and speed up the process of getting it fixed.
Short Microsoft support is no picknick eitherWell, since I'm the first, lets speak out the obvious:
I think that it is shame that a magazine of the scientific standing like Science and Nature take a stand in such debated terrain as patents on genomes.
As authorothies in science-land they should at least keep up the *appearance* of impartiality.