Non-sissy programmers make mistakes that can let in all sorts of problems with buffer-overruns and other fun vulnerabilities. C is a terrible language for trying to write "secure" or "safe" code.
I'm not saying C is bad for all situations. I just wouldn't use a saw to drive a nail.
By the same token I try not to find problems for my solution.
It may be very simple to do the refernce counting by hand, I'm just saying that it's possible to do a lot of this stuff automatically in a language design. See Limbo. It even has a way to get out of dreaded cycles that cause reference counting to leak memory [a cyclic keyword]. It's a shame Limbo only really works with the Inferno OS.
Also C++ has libraries of things like shared_ptr that do the reference counting in the constructors and destructors of the object. It also can suffer from the cyclic reference leaks of course but the need to double check code or even suspect it of being wrong at the "use" level is greatly diminished.
At the end of the day it's worth noting that no language is perfect, and just knowing the syntax doesn't make you a good coder. It takes practice... and just having a degree in CS isn't gonna make you great.
The problem is you can still change data in const objects. In some cases it's necessary - hence the "mutable" keyword.
Once made a class that abstracted a file as an array of records. To be able to make a const version of this that could still read the backing file, I had to have read pointers into the file as "mutable". There is still changeable state, it's just more controlled.
const is really not a very good guarantee that things won't be changed. The language lets you get around it too many ways.
And I think your code will actually run, too. I like the semantics (put the tail of the string into temp, put the head in the tail, and put the temp into the head -- more like English).
It's actually guaranteed by the C standard to work:). However the code generated is a 3rd form on a lot of non-optimizing compilers. So now you have pointer arithmetic, the canonical array[index], and the strange but valid index[array].
I work there and I worked on our MPI-IO implementation. I'm sure we'd like to find a way to help you out if you aren't against paying for the software.
mean, right now Darwin doesn't run on any x86 other than the 440BX chipset.
You are misinformed. It used to run just fine [Darwin 7.x series] on my Nforce2 based motherboard complete with networking and other fun stuff [need a 3Com adapter but it worked]
Now, we have issues with the lack of SSE2 and a few other hardware incompatibilies for my AMD Athlon.
Mac OS X does not use Mach like a microkernel at all. I wish people'd get this through their thick skulls.
It uses Mach and BSD in THE SAME ADDRESS SPACE. As such, it's basically as monolithic as it gets. It just happens to incoporate Mach in the kernel space and uses it for threads and IPC.
Anyone who takes 10 minutes to look at the Darwin documentation would know this.
Yeah, I've been meaning to take a good look at D for a long time. If anything can evolve C++ in the ways I think it might need to in the future, it's D.
Simple problem is that I've been hobbying with functional languages in my spare time lately and D just doesn't appear to be available on all the platforms I'd like to use it on.
How difficult would it be to get D on Mono? That might help get people into it.
I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.
That explains your preference of Objective C. It's a lot more like Smalltalk.
When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finished later.
So you like Objective C because it's easier to compile everywhere than a C++ program?. That's complete crap and I'm sure you know it. C++ doesn't require anywhere near the amount of runtime support that Objective C does. Most of the new Objective C code written today is confined to a single platform, Mac OS X. How is that code portable?
There was once a time when OpenStep was more evenly distributed and portable but now all we have is Cocoa and GNUStep.
I find this particular line of argument to be invalid.
By the time I looked at it again, computers were fast enough so that "scripting" languages like Python were practical for big projects, and elegant enough to write good programs in. C++ was still a gigantic clunky mess. I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused. And any language that "mangles" things should be avoided I think.:-)
No doubt, the language is complicated and requires more attention to details than C or your favorite scripting language of the day.
Also Java looked like "what C++ should've been".
I use Java almost every day now. I have to code back in the features I liked that came with C++'s STL in Java generics because C++ was just better targetted at generic programming it seems. The STL is a very powerful mechanism. Templates, not generics, are also very powerful and a surprising number of compilers are getting it done correctly these days with little to no code bloat.
Of course the way I use templates [metaprogramming] is probably more advanced than someone who claims to not see the point of C++ could easily understand.
And now the programming world seems to be returning to a desire for simplicity, elegance, "Agility", and C++ just doesn't cut it. My favorite language today for practical work is Ruby, with the occasional C extension.
C++ is very agile. You're not even making a real argument. I've seen C++ used in embedded systems, microkernel implementations, web servers, High Performance Computing projects. In fact it's a simple fact that even with the added language complexity some C++ code can end up ALWAYS being faster than the equivalent C code. [due to judicious use of things like templates, objects, and functors].
Actually it might be a bit more than a function call...
If operator == is defined outside a class defintion either the right or the left hand side of == could have an implicit conversion performed if there is a single argument, non-explicit-labelled, constructor to go from the type on the left to the type on the right or the right to the left.
Truth is by looking at a line of code you have to know a lot more about the types involved, how they are defined, and other stuff to know what's going on.
No good C++ programmer will tell you that it's easier to account for the impact of a line of C++ vs a line of C.
Don't get me wrong either. C++ kernels can exist and can be VERY fast. Check out L4 Pistachio if you don't believe me. It's also highly cross platform compatible [works on many systems].
They have wisely restricted themselves to a subset of features of the C++ language but have done a great job using the language without going nuts on features. I think it all comes down to discipline.
If I had it my way you wouldn't write kernels in any C-like language at all. I think C is the root of buffer overruns and other security problems. More rigorously type checked languages like Ada95 or even some functional langs like Haskell would make ideal languages for a kernel if they generate good enough code:). I think Pre-Scheme developers would agree with me.
In the meantime people can look at safe C dialects like Cyclone and get similar benefits.
Linus Torvalds has said he's been working on a type checking lint tool for his kernel. Good on him, I say:). That's exactly the right direction for the system to go. I don't think he'd be against a language with stronger typing either if he could get similar guarantees for code generation as C. It almost always comes down to implementation details [of the language].
Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.
It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this for more information.
The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.
I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.
As you can probably tell. I was impressed.
If you don't want to mess with installing over you existing OS you can try Inferno which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.
Wow that's really not the case at all. Darwinports by default installs stuff to/opt/local so it doesn't do what you just described. I suppose asking people to check their facts before posting to slashdot.org is too much work though.
Now you have an "informative" post with false information in it. Good job:)
Oh it works all right. I have it on my TiBook G4 667. But its not an official platform.
The networking and multi-user work too. If you are really interested in trying this then you should join the appropriate mailing list and give us a holler. We'll try to help if we can:).
As far as I know... and I have been following the list as well as reading the website... I see no plans to rely on fine-grained locking as an SMP enabling mechanism. There is an AmigaOS based messaging system that will allow people to run things like Filesystem drivers in userland should they choose to or they can keep it in ther kernel.
But why are you reading/. comments to find out what this thing is? Go to the website and see for yourself.
actually... I think its more about bang for the buck if you are interested in the latest and greatest hardware. For most PPC users it has been about the efficiency of the CPU [perhaps in the embedded market, where power consumption and heat dissipation are more important] or Mac users who love their OS and find the PPC is "enough" to get the job done and don't care about being "bitchin fast!" [The G5 helps narrow the speed gap however].
Ultimately I look at 3 things when I purchase a machine: 1) Price 2) performance 3) package. What am I getting for my 3000 dollars? Is it just really good hardware and no software? WIll it run the stuff I want to run [both meanings... hardware is fast enough to do what I need and can it physically run the software like Mac OS X]. The package part can be trickier. What does apple give its customers? Generally pretty damned good patching of security issues [screensaver passwords are easy.. log the hell out !</somewhat tounge-in-cheek>] Nice free software.. You also get access to a community of both geeks and artists as you become one of "the club". Its quite compelling... it doesn't have to be the fastest to feel like the best deal. And really... feeling good about your purchase is the only level of satisfaction you may need with your new machine and, for me, being able to do the things I need to get done on it is all I need to feel good.
Of course everyone's values are different and buying a PC isn't any more morally wrong than buying a Mac... its just a matter of preference.
Smeagol is a 32-bit operating system, though certain libraries and other elements have been recoded to allow applications - and the OS itself - to make use of the 64-bit addressing and datapaths, sources close to Apple said. For example, that's how the Power Mac G5 is able to support at least 8GB of memory, double the 32-bit limit of 4GB. Panther will adopt the same approach, said the source.
Don't Pentiums with PAE have this ability. 64 bit doesn't mean "double" the addressability. A fully 64bit address is 2^32 * 2*32 or roughly 4 billion SQUARED. Somone needs to learn binary:).
The Opteron doens't have full 64bit addressing either... I think its like 42 or 48bits.
It *does* have support for sound blaster 16... I used its sound recorder to record myself playing bass a few times. Its also got web browsers, modem dialers, and it had support for my Nvidia GeForce2 card [though I don't know that it was accelerated:)].
Anyway it was a fun system to play with... I couldn't find enough user software packages to keep me interested in it though.
Funny... it runs great on my A7N8X-deluxe. I just started working with Soren Schmidt to try and support the SATA chipset on this motherboard for future releases of FreeBSD also. I run FBSD-CURRENT and it seems fine to me.
I started with the RC and CVSup'd to the latest last night.
Check Mellanox. I work for MPI-Softtech and we are releasing a product soon for MPI over Infiniband. We get killer speeds out of it. There are at least two vendors still in the Infiniband market.
Don't lose hope... we are out there... just need to get the word out!
Slashdot Mirror
Non-sissy programmers make mistakes that can let in all sorts of problems with buffer-overruns and other fun vulnerabilities. C is a terrible language for trying to write "secure" or "safe" code.
I'm not saying C is bad for all situations. I just wouldn't use a saw to drive a nail.
By the same token I try not to find problems for my solution.
It may be very simple to do the refernce counting by hand, I'm just saying that it's possible to do a lot of this stuff automatically in a language design. See Limbo. It even has a way to get out of dreaded cycles that cause reference counting to leak memory [a cyclic keyword]. It's a shame Limbo only really works with the Inferno OS.
Also C++ has libraries of things like shared_ptr that do the reference counting in the constructors and destructors of the object. It also can suffer from the cyclic reference leaks of course but the need to double check code or even suspect it of being wrong at the "use" level is greatly diminished.
At the end of the day it's worth noting that no language is perfect, and just knowing the syntax doesn't make you a good coder. It takes practice... and just having a degree in CS isn't gonna make you great.
C++ has changed by leaps and bounds since 89... In fact, I know very few people who are even slightly interested in it for OOP.
That said, I still think it's a freaking mess and that you'd be far better off learning Lisp of Haskell for a well thought out language.
C++ has evolved... and it shows. It's got some really pointy edges you can cut yourself on.
Objective-C is a pretty decent OOP language extension for C... I just hate having to do reference counting myself.
The problem is you can still change data in const objects. In some cases it's necessary - hence the "mutable" keyword.
Once made a class that abstracted a file as an array of records. To be able to make a const version of this that could still read the backing file, I had to have read pointers into the file as "mutable". There is still changeable state, it's just more controlled.
const is really not a very good guarantee that things won't be changed. The language lets you get around it too many ways.
And I think your code will actually run, too. I like the semantics (put the tail of the string into temp, put the head in the tail, and put the temp into the head -- more like English).
:). However the code generated is a 3rd form on a lot of non-optimizing compilers. So now you have pointer arithmetic, the canonical array[index], and the strange but valid index[array].
:)
It's actually guaranteed by the C standard to work
I was just adding mud to the pool
Dave
{ }
That'll teach ya.
http://www.verarisoft.com/
I work there and I worked on our MPI-IO implementation. I'm sure we'd like to find a way to help you out if you aren't against paying for the software.
mean, right now Darwin doesn't run on any x86 other than the 440BX chipset.
You are misinformed. It used to run just fine [Darwin 7.x series] on my Nforce2 based motherboard complete with networking and other fun stuff [need a 3Com adapter but it worked]
Now, we have issues with the lack of SSE2 and a few other hardware incompatibilies for my AMD Athlon.
Mac OS X does not use Mach like a microkernel at all. I wish people'd get this through their thick skulls.
/. would actually edit for content.
It uses Mach and BSD in THE SAME ADDRESS SPACE. As such, it's basically as monolithic as it gets. It just happens to incoporate Mach in the kernel space and uses it for threads and IPC.
Anyone who takes 10 minutes to look at the Darwin documentation would know this.
I wish
Yeah, I've been meaning to take a good look at D for a long time. If anything can evolve C++ in the ways I think it might need to in the future, it's D.
Simple problem is that I've been hobbying with functional languages in my spare time lately and D just doesn't appear to be available on all the platforms I'd like to use it on.
How difficult would it be to get D on Mono? That might help get people into it.
I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.
:-)
That explains your preference of Objective C. It's a lot more like Smalltalk.
When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finished later.
So you like Objective C because it's easier to compile everywhere than a C++ program?. That's complete crap and I'm sure you know it. C++ doesn't require anywhere near the amount of runtime support that Objective C does. Most of the new Objective C code written today is confined to a single platform, Mac OS X. How is that code portable?
There was once a time when OpenStep was more evenly distributed and portable but now all we have is Cocoa and GNUStep.
I find this particular line of argument to be invalid.
By the time I looked at it again, computers were fast enough so that "scripting" languages like Python were practical for big projects, and elegant enough to write good programs in. C++ was still a gigantic clunky mess. I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused. And any language that "mangles" things should be avoided I think.
No doubt, the language is complicated and requires more attention to details than C or your favorite scripting language of the day.
Also Java looked like "what C++ should've been".
I use Java almost every day now. I have to code back in the features I liked that came with C++'s STL in Java generics because C++ was just better targetted at generic programming it seems. The STL is a very powerful mechanism. Templates, not generics, are also very powerful and a surprising number of compilers are getting it done correctly these days with little to no code bloat.
Of course the way I use templates [metaprogramming] is probably more advanced than someone who claims to not see the point of C++ could easily understand.
And now the programming world seems to be returning to a desire for simplicity, elegance, "Agility", and C++ just doesn't cut it. My favorite language today for practical work is Ruby, with the occasional C extension.
C++ is very agile. You're not even making a real argument. I've seen C++ used in embedded systems, microkernel implementations, web servers, High Performance Computing projects. In fact it's a simple fact that even with the added language complexity some C++ code can end up ALWAYS being faster than the equivalent C code. [due to judicious use of things like templates, objects, and functors].
So, to me, C++ is an obsolete language.
<*Shrug*>
/usr/dave is where my home is on Plan 9 even. Unix System Resources??? Where the hell did you get that?
Actually it might be a bit more than a function call...
:). I think Pre-Scheme developers would agree with me.
:). That's exactly the right direction for the system to go. I don't think he'd be against a language with stronger typing either if he could get similar guarantees for code generation as C. It almost always comes down to implementation details [of the language].
If operator == is defined outside a class defintion either the right or the left hand side of == could have an implicit conversion performed if there is a single argument, non-explicit-labelled, constructor to go from the type on the left to the type on the right or the right to the left.
Truth is by looking at a line of code you have to know a lot more about the types involved, how they are defined, and other stuff to know what's going on.
No good C++ programmer will tell you that it's easier to account for the impact of a line of C++ vs a line of C.
Don't get me wrong either. C++ kernels can exist and can be VERY fast. Check out L4 Pistachio if you don't believe me. It's also highly cross platform compatible [works on many systems].
They have wisely restricted themselves to a subset of features of the C++ language but have done a great job using the language without going nuts on features. I think it all comes down to discipline.
If I had it my way you wouldn't write kernels in any C-like language at all. I think C is the root of buffer overruns and other security problems. More rigorously type checked languages like Ada95 or even some functional langs like Haskell would make ideal languages for a kernel if they generate good enough code
In the meantime people can look at safe C dialects like Cyclone and get similar benefits.
Linus Torvalds has said he's been working on a type checking lint tool for his kernel. Good on him, I say
Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.
It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this for more information.
The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.
I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.
As you can probably tell. I was impressed.
If you don't want to mess with installing over you existing OS you can try Inferno which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.
Wow that's really not the case at all. Darwinports by default installs stuff to /opt/local so it doesn't do what you just described. I suppose asking people to check their facts before posting to slashdot.org is too much work though.
:)
Now you have an "informative" post with false information in it. Good job
Oh it works all right. I have it on my TiBook G4 667. But its not an official platform.
:).
The networking and multi-user work too. If you are really interested in trying this then you should join the appropriate mailing list and give us a holler. We'll try to help if we can
As far as I know... and I have been following the list as well as reading the website... I see no plans to rely on fine-grained locking as an SMP enabling mechanism. There is an AmigaOS based messaging system that will allow people to run things like Filesystem drivers in userland should they choose to or they can keep it in ther kernel.
/. comments to find out what this thing is? Go to the website and see for yourself.
But why are you reading
actually... I think its more about bang for the buck if you are interested in the latest and greatest hardware. For most PPC users it has been about the efficiency of the CPU [perhaps in the embedded market, where power consumption and heat dissipation are more important] or Mac users who love their OS and find the PPC is "enough" to get the job done and don't care about being "bitchin fast!" [The G5 helps narrow the speed gap however].
Ultimately I look at 3 things when I purchase a machine: 1) Price 2) performance 3) package. What am I getting for my 3000 dollars? Is it just really good hardware and no software? WIll it run the stuff I want to run [both meanings... hardware is fast enough to do what I need and can it physically run the software like Mac OS X]. The package part can be trickier. What does apple give its customers? Generally pretty damned good patching of security issues [screensaver passwords are easy.. log the hell out !</somewhat tounge-in-cheek>] Nice free software.. You also get access to a community of both geeks and artists as you become one of "the club". Its quite compelling... it doesn't have to be the fastest to feel like the best deal. And really... feeling good about your purchase is the only level of satisfaction you may need with your new machine and, for me, being able to do the things I need to get done on it is all I need to feel good.
Of course everyone's values are different and buying a PC isn't any more morally wrong than buying a Mac... its just a matter of preference.
actually I only accounted for the leftmost bit on an unsigned 64bit value I suppose :).
Smeagol is a 32-bit operating system, though certain libraries and other elements have been recoded to allow applications - and the OS itself - to make use of the 64-bit addressing and datapaths, sources close to Apple said. For example, that's how the Power Mac G5 is able to support at least 8GB of memory, double the 32-bit limit of 4GB. Panther will adopt the same approach, said the source.
:).
Don't Pentiums with PAE have this ability. 64 bit doesn't mean "double" the addressability. A fully 64bit address is 2^32 * 2*32 or roughly 4 billion SQUARED. Somone needs to learn binary
The Opteron doens't have full 64bit addressing either... I think its like 42 or 48bits.
It *does* have support for sound blaster 16... I used its sound recorder to record myself playing bass a few times. Its also got web browsers, modem dialers, and it had support for my Nvidia GeForce2 card [though I don't know that it was accelerated :)].
Anyway it was a fun system to play with... I couldn't find enough user software packages to keep me interested in it though.
At 11:30PM on Friday the CEO of IBM should fax SCO a Xerox of his butt. That seems an appropriate response.
With a post-it on it saying "apply lips here".
Funny... it runs great on my A7N8X-deluxe. I just started working with Soren Schmidt to try and support the SATA chipset on this motherboard for future releases of FreeBSD also. I run FBSD-CURRENT and it seems fine to me.
I started with the RC and CVSup'd to the latest last night.
Is that an nForce2 chipset?
Don't forget about Darwinports.
Here's the URL MPI-Softtech
Check Mellanox. I work for MPI-Softtech and we are releasing a product soon for MPI over Infiniband. We get killer speeds out of it. There are at least two vendors still in the Infiniband market.
Don't lose hope... we are out there... just need to get the word out!