Are any of the Sather variants alive? Last I had looked the newgroup was spam only, and it looks like Berkely and Karlsrhue have stopped any development and support. I'm not sure if anyone in the GNU world has picked it up or not. I agree that it was slick but it looks dead. Eiffel is a nice idea for this stuff, we just don't have a good compiler and I think that Meyer did enough damage early on that it will forever be a tainted language in many minds. I respect them both but I just can't see how sather or eiffel is a realistic choice unless someone is getting very serious about building new compilers.
I'd love OCaml, it's not nearly as difficult for uneducated programmers to use (meaning, you typically only see functional programming in academia..) as Standard ML and others. It has decent bindings and amazing performance. I'm not sure Inria will ever let it go though. THe more I use ocaml the more I fall in love with it; I wouldn't be against an effort to use it.
Save for Ocaml, I see us have 4 legitimate contenders: C++. Objective-C, Mono, and I'm throwing Gnat in to the mix only because it's an amazingly high quality compiler. Thinking long term, I think we have to factor the tool quality in to this as well as the free nature and the support the tools have. GCC stands far above the rest in this reguard. Python, Perl/Parrot, Ruby, etc. don't offer the native compiled code performance that is critical for desktop apps. Java doesn't really offer it either, mono may not.
What I don't understand is why a set of C++ guidelines couldn't be agreed to, Mozilla did, KDE did. C++ is incredible when done correctly, yeah you and do stupid stuff but it's supported, the compiler is good and there is a proven track record of big projects using it. Not optimal but it's there and it works. Come up with a solid set of GNOME coding guidelines and let it rip, it's an evolutionary change rather than a disruptive one and since all the technology is there and proven I trust that it can be made to work. If not C++ then I think you have to really rule out Objective-C, it's alive, serious dev is being done on Objective-C++ and Apple is using it.
The mono stuff looks cool, I just have reservations, seems like there should be an agreement with MS on it. Else, we're strapped in to playing catch-up all the time or sued for copying something. Something else and this affects Java as well; ANSI and ISO have good standards cycles, you can deploy a standard and it's there for a while. Sun and MS, really they started language versioning, have their own interests in mind and push the revs too quickly. Mono hasn't got to 1.0 yet and MS is already talking C# 2.0. Maybe it won't matter but we don't want to build a huge library of code up and then have the foundation technology stagnate or fall behind or become on available somehow.
I'm a math guy, I like to keep up on what's going on. I've got a
degree but I'm not of the cablibre of a professional mathematician.
One thing I've struggled with over the years since university is that
I simply cannot get access to good information. I know that various
things have been proven but unless I'm part of the AMS or I recieve
various obscure math journals I simply cannot get access to those
proofs. Even good libraries don't carry them.
There is a balance to achieve. Every one part of me would love to
have a set of DVDs for purchase (cheap, hopefully) from a web tome of
math. It would contain every proof known. At the same time, as a
former student I know the value of proving things on your own and the
value that comes from that creativity.
What's more scarry though is that a lot of this information simply
isn't distributed to enough places. Try to find a copy of the Erdos
Selzberg elementry proof of the prime number theorem. It seems like
it wouldn't take that much for that knowledge to be lost. More
importantly, I think it creates a bad scientific culture. I've never
read the elementry proof of the prime number theorem, I know it
exists, I believe it has been proven but I can't verify it for
myself. You know and this is just math. I think we're getting to the
point where all scientific knowledge should be public. Public
journals and stuff like that make the most sense and a large internet
based repository would be ideal, with some kind of controls, I'd pay
a fee for access to it if it was nominal. We're not talking about
Hollywood movies and crap like that, we're talking about real
knowledge.
As we start to issue policy from science, like the Kyoto treaty, we
need to have a real open review process to measure the data, to
examine that science actually took place. Not everybody is capable of
reading through that kind of data and drawing logical conclusions but
an effort has to be made, we've already seen high stakes scientific
fraud over the last few years; things that got very public before
they were caught and there were only a handful of people that could do
the review.
I have developed a commercial set-top box that used ideas from LinuxBIOS. It's kind of a bootloader, like there are on non-x86 machines.
How it typically works is you develop a kernel with a small foot print. The LinuxBIOS guys are really sane about things, there is a few lines of assembly which is just about enough code to start running C code. After that the gist of it is C with some assembly macros. There isn't anything too complex, we're talking about outp mostly. There isn't anything too secret here, it's just that booting a PC is not documented really well. Some BIOS vendors have software that does runtime function with system managment interrupts. DRM will be something like that. Supposedly and there have been discussions about it on the LinuxBIOS list, Phoenix and company do some hardware error checking and such and that's why they are so slow but some of the LinuxBIOS folks think that they don't do that and that the code is so complex and has so much legacy that it does a bunch of extra crap that it doesn't need to.
That code does enough to turn on memory, it may do some checking now, when I looked at it last there wasn't a ton of integrity checking code. Light up a few other components, like VGA. Then copy a kernel from flash in to memory (think of it as a slightly tweaked bzImage) At that point you can pretty much jump to the start of the kernel and execute it. The kernel doesn't use BIOS for most device IO so it knows how to spin up drives and light up the rest of the hardware.
Now how we did it and understood the goal of LinuxBIOS to be was we had an initrd that the kernel from flash would load and execute. Said initrd would look at the drives, look at some other variables, authenticate the system, possibly do a fsck on the disks if needed and then locate a kernel on the disk. After locating that kernel it would use kexec, now called fastboot, and replace the kernel in memory. The idea was that we could upgrade kernels on disks without changing flash.
It works very well and has been incredibly reliable. We can get in to kernel space in a few seconds. Subsequently, if it's a settop box type device, it could download a brain from cable or satellite. It could rebuild itself if needed. You could have diagnostic code in there for manufacturing, etc, whatever you want. Pretty much only limited by flash size and memory.
I know that they now and do other things like boot windows and such, at which point LinuxBIOS is potentially a serious threat to Phoenix and company, the BIOS is an expensive piece of the computer.
I've been toying around with some linuxbios type projects. Since disk space is so insanely cheap and disks are so big anymore, you could set aside a backup partition, easily do a really quick backup daily and then weekly do a backup of that to long term media from "BIOS land" regardless of the operating system. Or you could have something like snapshots of your system, maybe a clean install, a configured system, a backup, a different OS or something like that and then all from "BIOS Space" pick them at boot time and have it restore them. Something like that, I have always wanted backup support at the BIOS level.
Once the masses were illiterate, then they were taught to read and at that point they can start to make their own decisions. Wasn't the rift between the Catholic chuch and the protestants because of Martin Luther's belief that people other than clergy were able to read the Bible and interpret it? Same kind of revolution here, just much smaller scale. Martin Luther spawned a religious revolution that has resulted in thousands and thousands of different sects, cults, and belief structures. Some are good, some are bad; a small handful of grown up in to quite robust churches with well developed dogma and beliefs. A lot of nasty stuff happened as a result also but by in large the world seems to be a far better place today than it was then.
Broadband isn't the cause of vulnerabilities, it just exposes them. These are all problems that have already been there and never fixed. Will there be another virus that infect millions and millions of people? Sure, stoned and jerusalem did too and stoned required a floppy to be booted in a computer back in the day. People shouldn't run programs they get from the net without caution. That's what they said about BBSes 20 years ago.
Give it time, things will work themselves out. To be honest I'm far more worried and some of the more modern attacks that attack the fundamental trust models. There is a TTL attack where you can carefully craft packets with screwy TTL values and a 56K link can DoS a 3Mbit link, that's just exploiting the way the protocol is designed to work. Should attacks like that become really pervasive that is something that can cause damage.
What's with all the negativity?
on
Fault Tolerant Shell
·
· Score: 4, Interesting
I know that if you need a ton of fault tolerance in your shell scripts that you should probably be using a different language but every time I look at any complex systems, not just a signle app but a system, there is always shell script glue. More importantly, I've never seen a shell script that checked the return codes of everything at best they look at a few key components and report on their success of failure. Exceptions would be nice.
I think perl is where it is because so many people use it as "super script." To me that says, a) we recode all the Bourne and csh and bash in perl or b) we look at why people do shell scripting in perl or other languages and add that to the shell. I couldn't tell you which is right. It's a neat idea though and I'm glad they made it.
A real example I can think of, I had a test machine that had some kind of ext3 corruption and so it mounted up in read-only mode when it booted. I spent time diagnosing an application error in our application because nothing caught that; these are redhat type startup scripts. I noticed that our app couldn't write logs and began to debug the system. More interestingly, a dozen or so start-up scripts failed to start up critical components and their failure wasn't noticed. If you can't write to the filesystem, you can't create a socket(AF_UNIX) and all sort's of things go tits up then. If that's how you debug it's only going to get more difficult as you add more and more complexity, you have to detect the lower level failures and report them. Perversely, this wouldn't have been noticed had a different partition been read-only. Turns out that a drive was going bad. Had it been a different partition, it would have been noticed at catastrophic system failure time when the drive died.
I've done a fair amount of embedded work and there is always a test for new guys, you can tell the new guy (new college grad, whatever) because he skips half or more of the error checking in his code. You know printf returns a value? Funnier still, if you develop something like a consumer app in embedded space, you'll eventually see things like printf fail. We know it never should, but with 20,000+ users in different environments and what not, things like that can and do fail and usually point to a greater problem, like a dead drive or something. Instead of logging/alerting something to the critical and unusual printf failure, the app fails in a different way because this printf failed. Heaven forbid that it was sprintf that failed and then you shove bad data in to a database or configuration file and not just fail the system but corrupt the data too. Inspite of all of that, even veterans will forget error checking at times, it's a common bug and so having higher level tools to help assist, like exception in the shell can only be a good thing.
It seems most people who claim to be C++ programmers just say that because they use a C++ compiler and stick their functions in objects.
And here is the problem. I'm a C++ programmer and I have to admit since ANSI and ISO have standardized it and templates have got to a nice place, it's really quite a nice language. The problem is the complete lack of real C++ developers. I say this being a user of the language since the late 80's, going through compiler hell and seeing the rise of java.
Perfect for everything, no. It's a great tool more often than not though. They have made it a better language.
I hate these language discussions, "foo is dead, long live bar." If you think C has no value, you are either clueless or you work in such a tiny box that you have no idea how the rest of the computing world works. I'd argue that C is a nearly perfect tool for driver and kernel development. I hate writing GUI apps in it but in some domains nothing has ever demonstrated itself better. As for building GUIs and what not, mono does look pretty compelling, I've hacked around with gtk# and it seems like I can make an app do what I want in half the code of C++ or C.
* Note that the GPL places important restrictions on "derived works", yet *
* it does not provide a detailed definition of that term. To avoid *
* misunderstandings, we consider an application to constitute a *
* "derivative work" for the purpose of this license if it does any of the *
* following: *
* o Integrates source code from Nmap *
* o Reads or includes Nmap copyrighted data files, such as * nmap-os-fingerprints or nmap-service-probes. * o Executes Nmap
* o Integrates/includes/aggregates Nmap into an executable installer * o Links to a library or executes a program that does any of the above
Now the part that stands out to me other than simply providing a different document and calling it GPL is
* Note that the GPL places important restrictions on "derived works", yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a "derivative work" for the purpose of this license if it does any of the
following:.... o Executes Nmap
The way I read that, he says if you execute nmap from any other program then you are creating a derivative that is covered by the GPL. I don't know how your OS works but mine works with a program called a kernel that executes a lot of other programs. Even if the kernel doesn't directly execute it, bash, cmd.exe, tcsh, or some other "program" does execute it and as I read this extension to the GPL, what ever program that is needs to be GPL compliant.
Check this out COPYING
this is the modified GPL that Fyodor claims to distribute nmap under. As you can see, it's clearly not the GPL. You can't even execute nmap on a non-free operating system.
Do you say "can" meaning it is possible in the real of theory or "can" meaning that there is a practical situation where it happens?
I have yet to see an example of it. I have also yet to see it established that runtime optimizations actually buy you anything above what a modern compiler can do, the compiler knows far more about the code the runtime knows far more about the system in question; prove that runtime is better than global optimization up front. It sounds really nice in theory and it makes conceptual sense but that doesn't make it true.
If you can come up with an example of hotspot tweaking some loop such that it outperforms a native compiler, I'll be impressed. Of course I'll just pull out PGO and make sure my native code wins again and doesn't have all the start up problems or need as much memory, but I'll still be impressed if someone can do it.
I don't know about "building their business" what they should have done was put together a serious legal defense fund and established a legal dream team up front.
Of course, what's the cost of a Hummer or Harley compared to a set of really really good layers? It's like round off error.
I think AMD has done tremendous things for this industry the last few
years, it's nice to see them having something that looks like the
lead and upper hand for a change. Competition is good for everyone.
Let's not get ahead of ourselves though, I'd never underestimate a
company like Intel but for now it looks like AMD is fighting a great
fight.
On the downside, I kind of liked the IA64 architecture, I'm not a
hater or a lover the x86 but I would have loved for IA64 to start
taking off, it just looks like a clean architecture. We're talking
about a 10year+ effort by one of the largest and most powerful
companies in the world that is sputtering out. That seems so epic (no
pun) to me in the post dot.com world where everything is about speed
to market; how many 10year efforts are out there any more? I can only
assume that this is kind of a death knell for IA64, especially if MS
appears to be on the x86-64 bandwagon. Looks to me like HP and Intel
are IA64's only supporters and they don't write that much software
between the two of them. Can anyone offer some insight in to how the
company that has beat much of the competition in to submission with
price/performance has floundered IA64 so badly? Is there a fear of
reducing their future margins by making IA64 affordable, like they
won't be able to charge $3000 a chip? It's just such a talented
group of people that make up Intel (I literally mean that and have
tons of respect for them, they *know* how to build chips) I just
don't understand it, I expected them to start turning the crank and
be selling IA64s for the same cost a Xeons and at that cost we'd all
be buying IA64s for our servers. This has to be more than politics.
They simply bite off too much?
This is good. How many companies have the source to windows? IBM, ComHpaq, Motorola, a handful of others. With HP falling limp on Itanium and Sun being Sun, IBM is kind of in this poised-to-take-over position. We all now 64bit computing is spelled POWER... SCO is already beating up on them, it would be natural for MS to try to hang something like this on them.
Kenisis rocks! I've bought a lot of cool computer toys over the years but the contour and advantage may be my favorites, you can feel the difference and I have never had carple tunnel.
We should follow the military on this, you want a security clearence you know what they look for? They look at your financials like nothing else because that is how you're blackmailed or instable. Most of the spies that have damaged our country did it for the money, very few did it for ideology. You can probably have DUIs and drug arrests and become a secret service agent easier than having a some late bill payments on your credit.
What do you think goes throught the mind of a projector jockey making $6-$15 an hour showing the same shitty movies over and over and over. Shit, the managers of the places don't make crap. And it's not like the industry doesn't brag about its money, that's all you hear about movies in the news, "record breaking weekend," "record opening," "biggest budget ever." I mean in a recession, a movie and dinner date is what? $50 to $100 depending on if you have drinks with dinner, you think the people working at the theater can afford that with their disposable income?
If I was working at a theater, I could possibly start boot legging, you can buy a decent recorder cheap and then if you had the connections to sell the movies you could easily make a lot more than you'd ever get at a theater. That's just simple economics. You want loyalty you have to fork out some more money. I'm not saying it's right to do it or anything but you get what you pay for and the movie biz is extremely top heavy paying people 10s of millions of dollars regularly where the people taking your tickets and cleaning up the theaters and actually showing the movies make squat.
Re:How are we going to explaing something this sub
on
G5 vs Opteron, Finally
·
· Score: 1
Doesn't it remain to be seen if AMD64 64bit code is any faster than the 32bit counterpart? I haven't seen any documentation to that fact.
Moreover, I don't know of a good optimizing AMD64 compiler that fully exploits the architecture. PGC might be okay, Metrowerks has a long history of building shitty compilers (my professional opionion) any compilers that anyone has experience with?
I think that you can probably get a lot more out of both chips. Most of those mac apps are compiled with GCC, which is great but xlC is a ton better on POWER and PowerPC.
Of course. If you increase failure rate with stupidity then you'll never win. I think Gordon Moore said it a little differently. "If you aren't failing then you aren't trying hard enough."
The original point is good, I still think more companies are blowing up because they are doing foolish things. Starting a company is very hard work and there is a lot of it. You either have to be a lot smarter than the competition or work a lot harder, no way around that and you're probably not that much smarter. The startup I'm with has busted our asses but it's looking positive, during the roughest parts I hated it but now looking back, it's the only way we've survived and done as well as we have.
You want to hear my BeOS experience? I thought it might be a fun niche. I forked out the cash, I bought the OS, bought the metrowerks dev kit, bought the books. Opened up and I was amped. It was a fun toy. I joined the dev program. 6+ years ago MW and Be were promisng a java port, I thought that would be nice and make this legitimate. Never happened. Then they killed the MW deal and completely shifted to gcc, which is cool, it just cost me $200+. At least I didn't buy in to the PowerPC idea...
The whole time, being a Linux user and developer, I was talking about opensourcing this and that, there was so much opensource in BeOS to begin with, why not take the bull by the horns. Be used Linux as a host platform to develop beos. Be used GCC. Be carped driver designs, and an OS platform from GPL libre software. Nothing ever happened. I even wrote to the company and explained it, the response is that we don't want to help linux, we want to be Be. Now the community is doing this and they are still against Linux; their FAQ even mentions that OpenBeos on linux would be an extension to linux and that is somehow a bad thing.
Long story short, I've got no sour grapes, I don't care about the money, time, effort or anything else, I think some of the ideas behind beos are cool. What chaps me is the unwillingness to play ball and the simple lack of a techincal explanation as to what Linux or BSD kernels (which ones did you look at?) doesn't do that the be kernel needs. Are we talking new APIs? Are talking messaging queues? Latency isn't there (I call bullshit on this one, especially with 2.4 and now 2.6) what exactly is it? In the interview he even says outright that he hasn't gone very deep, pretty much just dismissed it.
Be's problem as a company and a community has always been lot's of talk with no beef and some awful fear of playing with others. "Pervasive threading this," "media OS that" what does that mean? Why is it good? You'll never get an answer with numbers, at best "it feels" will be said. Further, in specifics, what is it that you need the linux kernel to do and why is it easier to start from scratch rather than fix linux to do that? Even if it isn't rolled into mainline, look at ucLinux, rtLinux, and other "forks." I'm simply asking as an engineer, which problem space is bigger? Again, I wish them well and have no real sour grapes other than I really want a project like this to succeed and from the information presented to me from them they aren't making good engineering decisions and aren't making a plan for success. If it's simply an experiment and they want to do it all then say that, but they aren't saying that and that makes me think they either don't know or it's some cultural flaw and either way I don't think it is a good thing for their success.
I understand that it's an opinion piece but what's the point. Really? I can't say that I've been inundated with "Mac OSX is more secure" noise from a lot of Mac fan boys.
In fact other than a few free/libre software idealists I can't say that I really associate with any sort of fan boys, not OSX vs. Windows, not PS2 vs. XBox, none of that shit. We grew up, got jobs and when we're not geeking or working we're talking about our wives and kids or doing something not computer related..
Slashdot Mirror
I'd love OCaml, it's not nearly as difficult for uneducated programmers to use (meaning, you typically only see functional programming in academia..) as Standard ML and others. It has decent bindings and amazing performance. I'm not sure Inria will ever let it go though. THe more I use ocaml the more I fall in love with it; I wouldn't be against an effort to use it.
Save for Ocaml, I see us have 4 legitimate contenders: C++. Objective-C, Mono, and I'm throwing Gnat in to the mix only because it's an amazingly high quality compiler. Thinking long term, I think we have to factor the tool quality in to this as well as the free nature and the support the tools have. GCC stands far above the rest in this reguard. Python, Perl/Parrot, Ruby, etc. don't offer the native compiled code performance that is critical for desktop apps. Java doesn't really offer it either, mono may not.
What I don't understand is why a set of C++ guidelines couldn't be agreed to, Mozilla did, KDE did. C++ is incredible when done correctly, yeah you and do stupid stuff but it's supported, the compiler is good and there is a proven track record of big projects using it. Not optimal but it's there and it works. Come up with a solid set of GNOME coding guidelines and let it rip, it's an evolutionary change rather than a disruptive one and since all the technology is there and proven I trust that it can be made to work. If not C++ then I think you have to really rule out Objective-C, it's alive, serious dev is being done on Objective-C++ and Apple is using it.
The mono stuff looks cool, I just have reservations, seems like there should be an agreement with MS on it. Else, we're strapped in to playing catch-up all the time or sued for copying something. Something else and this affects Java as well; ANSI and ISO have good standards cycles, you can deploy a standard and it's there for a while. Sun and MS, really they started language versioning, have their own interests in mind and push the revs too quickly. Mono hasn't got to 1.0 yet and MS is already talking C# 2.0. Maybe it won't matter but we don't want to build a huge library of code up and then have the foundation technology stagnate or fall behind or become on available somehow.
There is a balance to achieve. Every one part of me would love to have a set of DVDs for purchase (cheap, hopefully) from a web tome of math. It would contain every proof known. At the same time, as a former student I know the value of proving things on your own and the value that comes from that creativity.
What's more scarry though is that a lot of this information simply isn't distributed to enough places. Try to find a copy of the Erdos Selzberg elementry proof of the prime number theorem. It seems like it wouldn't take that much for that knowledge to be lost. More importantly, I think it creates a bad scientific culture. I've never read the elementry proof of the prime number theorem, I know it exists, I believe it has been proven but I can't verify it for myself. You know and this is just math. I think we're getting to the point where all scientific knowledge should be public. Public journals and stuff like that make the most sense and a large internet based repository would be ideal, with some kind of controls, I'd pay a fee for access to it if it was nominal. We're not talking about Hollywood movies and crap like that, we're talking about real knowledge.
As we start to issue policy from science, like the Kyoto treaty, we need to have a real open review process to measure the data, to examine that science actually took place. Not everybody is capable of reading through that kind of data and drawing logical conclusions but an effort has to be made, we've already seen high stakes scientific fraud over the last few years; things that got very public before they were caught and there were only a handful of people that could do the review.
How it typically works is you develop a kernel with a small foot print. The LinuxBIOS guys are really sane about things, there is a few lines of assembly which is just about enough code to start running C code. After that the gist of it is C with some assembly macros. There isn't anything too complex, we're talking about outp mostly. There isn't anything too secret here, it's just that booting a PC is not documented really well. Some BIOS vendors have software that does runtime function with system managment interrupts. DRM will be something like that. Supposedly and there have been discussions about it on the LinuxBIOS list, Phoenix and company do some hardware error checking and such and that's why they are so slow but some of the LinuxBIOS folks think that they don't do that and that the code is so complex and has so much legacy that it does a bunch of extra crap that it doesn't need to.
That code does enough to turn on memory, it may do some checking now, when I looked at it last there wasn't a ton of integrity checking code. Light up a few other components, like VGA. Then copy a kernel from flash in to memory (think of it as a slightly tweaked bzImage) At that point you can pretty much jump to the start of the kernel and execute it. The kernel doesn't use BIOS for most device IO so it knows how to spin up drives and light up the rest of the hardware.
Now how we did it and understood the goal of LinuxBIOS to be was we had an initrd that the kernel from flash would load and execute. Said initrd would look at the drives, look at some other variables, authenticate the system, possibly do a fsck on the disks if needed and then locate a kernel on the disk. After locating that kernel it would use kexec, now called fastboot, and replace the kernel in memory. The idea was that we could upgrade kernels on disks without changing flash.
It works very well and has been incredibly reliable. We can get in to kernel space in a few seconds. Subsequently, if it's a settop box type device, it could download a brain from cable or satellite. It could rebuild itself if needed. You could have diagnostic code in there for manufacturing, etc, whatever you want. Pretty much only limited by flash size and memory.
I know that they now and do other things like boot windows and such, at which point LinuxBIOS is potentially a serious threat to Phoenix and company, the BIOS is an expensive piece of the computer.
I've been toying around with some linuxbios type projects. Since disk space is so insanely cheap and disks are so big anymore, you could set aside a backup partition, easily do a really quick backup daily and then weekly do a backup of that to long term media from "BIOS land" regardless of the operating system. Or you could have something like snapshots of your system, maybe a clean install, a configured system, a backup, a different OS or something like that and then all from "BIOS Space" pick them at boot time and have it restore them. Something like that, I have always wanted backup support at the BIOS level.
Broadband isn't the cause of vulnerabilities, it just exposes them. These are all problems that have already been there and never fixed. Will there be another virus that infect millions and millions of people? Sure, stoned and jerusalem did too and stoned required a floppy to be booted in a computer back in the day. People shouldn't run programs they get from the net without caution. That's what they said about BBSes 20 years ago.
Give it time, things will work themselves out. To be honest I'm far more worried and some of the more modern attacks that attack the fundamental trust models. There is a TTL attack where you can carefully craft packets with screwy TTL values and a 56K link can DoS a 3Mbit link, that's just exploiting the way the protocol is designed to work. Should attacks like that become really pervasive that is something that can cause damage.
I think perl is where it is because so many people use it as "super script." To me that says, a) we recode all the Bourne and csh and bash in perl or b) we look at why people do shell scripting in perl or other languages and add that to the shell. I couldn't tell you which is right. It's a neat idea though and I'm glad they made it.
A real example I can think of, I had a test machine that had some kind of ext3 corruption and so it mounted up in read-only mode when it booted. I spent time diagnosing an application error in our application because nothing caught that; these are redhat type startup scripts. I noticed that our app couldn't write logs and began to debug the system. More interestingly, a dozen or so start-up scripts failed to start up critical components and their failure wasn't noticed. If you can't write to the filesystem, you can't create a socket(AF_UNIX) and all sort's of things go tits up then. If that's how you debug it's only going to get more difficult as you add more and more complexity, you have to detect the lower level failures and report them. Perversely, this wouldn't have been noticed had a different partition been read-only. Turns out that a drive was going bad. Had it been a different partition, it would have been noticed at catastrophic system failure time when the drive died.
I've done a fair amount of embedded work and there is always a test for new guys, you can tell the new guy (new college grad, whatever) because he skips half or more of the error checking in his code. You know printf returns a value? Funnier still, if you develop something like a consumer app in embedded space, you'll eventually see things like printf fail. We know it never should, but with 20,000+ users in different environments and what not, things like that can and do fail and usually point to a greater problem, like a dead drive or something. Instead of logging/alerting something to the critical and unusual printf failure, the app fails in a different way because this printf failed. Heaven forbid that it was sprintf that failed and then you shove bad data in to a database or configuration file and not just fail the system but corrupt the data too. Inspite of all of that, even veterans will forget error checking at times, it's a common bug and so having higher level tools to help assist, like exception in the shell can only be a good thing.
And here is the problem. I'm a C++ programmer and I have to admit since ANSI and ISO have standardized it and templates have got to a nice place, it's really quite a nice language. The problem is the complete lack of real C++ developers. I say this being a user of the language since the late 80's, going through compiler hell and seeing the rise of java.
Perfect for everything, no. It's a great tool more often than not though. They have made it a better language.
I hate these language discussions, "foo is dead, long live bar." If you think C has no value, you are either clueless or you work in such a tiny box that you have no idea how the rest of the computing world works. I'd argue that C is a nearly perfect tool for driver and kernel development. I hate writing GUI apps in it but in some domains nothing has ever demonstrated itself better. As for building GUIs and what not, mono does look pretty compelling, I've hacked around with gtk# and it seems like I can make an app do what I want in half the code of C++ or C.
* Note that the GPL places important restrictions on "derived works", yet * * it does not provide a detailed definition of that term. To avoid * * misunderstandings, we consider an application to constitute a * * "derivative work" for the purpose of this license if it does any of the * * following: * * o Integrates source code from Nmap * * o Reads or includes Nmap copyrighted data files, such as * nmap-os-fingerprints or nmap-service-probes. * o Executes Nmap * o Integrates/includes/aggregates Nmap into an executable installer * o Links to a library or executes a program that does any of the above
Now the part that stands out to me other than simply providing a different document and calling it GPL is * Note that the GPL places important restrictions on "derived works", yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a "derivative work" for the purpose of this license if it does any of the following: .... o Executes Nmap
The way I read that, he says if you execute nmap from any other program then you are creating a derivative that is covered by the GPL. I don't know how your OS works but mine works with a program called a kernel that executes a lot of other programs. Even if the kernel doesn't directly execute it, bash, cmd.exe, tcsh, or some other "program" does execute it and as I read this extension to the GPL, what ever program that is needs to be GPL compliant.
I messed up the link: here
He's rattled his sabor before.
Point me to a situation where JIT out optimizes C++ in the real world.
I have yet to see an example of it. I have also yet to see it established that runtime optimizations actually buy you anything above what a modern compiler can do, the compiler knows far more about the code the runtime knows far more about the system in question; prove that runtime is better than global optimization up front. It sounds really nice in theory and it makes conceptual sense but that doesn't make it true.
If you can come up with an example of hotspot tweaking some loop such that it outperforms a native compiler, I'll be impressed. Of course I'll just pull out PGO and make sure my native code wins again and doesn't have all the start up problems or need as much memory, but I'll still be impressed if someone can do it.
Of course, what's the cost of a Hummer or Harley compared to a set of really really good layers? It's like round off error.
On the downside, I kind of liked the IA64 architecture, I'm not a hater or a lover the x86 but I would have loved for IA64 to start taking off, it just looks like a clean architecture. We're talking about a 10year+ effort by one of the largest and most powerful companies in the world that is sputtering out. That seems so epic (no pun) to me in the post dot.com world where everything is about speed to market; how many 10year efforts are out there any more? I can only assume that this is kind of a death knell for IA64, especially if MS appears to be on the x86-64 bandwagon. Looks to me like HP and Intel are IA64's only supporters and they don't write that much software between the two of them. Can anyone offer some insight in to how the company that has beat much of the competition in to submission with price/performance has floundered IA64 so badly? Is there a fear of reducing their future margins by making IA64 affordable, like they won't be able to charge $3000 a chip? It's just such a talented group of people that make up Intel (I literally mean that and have tons of respect for them, they *know* how to build chips) I just don't understand it, I expected them to start turning the crank and be selling IA64s for the same cost a Xeons and at that cost we'd all be buying IA64s for our servers. This has to be more than politics. They simply bite off too much?
This is good. How many companies have the source to windows? IBM, ComHpaq, Motorola, a handful of others. With HP falling limp on Itanium and Sun being Sun, IBM is kind of in this poised-to-take-over position. We all now 64bit computing is spelled POWER... SCO is already beating up on them, it would be natural for MS to try to hang something like this on them.
Plus drivers don't exactly count.
Kenisis rocks! I've bought a lot of cool computer toys over the years but the contour and advantage may be my favorites, you can feel the difference and I have never had carple tunnel.
You are confusing terabyte and tebibyte.
There was already an AIX client for notes with a motif GUI. It was a couple revs back but I don't think that it's quite as hard as you think.
We should follow the military on this, you want a security clearence you know what they look for? They look at your financials like nothing else because that is how you're blackmailed or instable. Most of the spies that have damaged our country did it for the money, very few did it for ideology. You can probably have DUIs and drug arrests and become a secret service agent easier than having a some late bill payments on your credit.
What do you think goes throught the mind of a projector jockey making $6-$15 an hour showing the same shitty movies over and over and over. Shit, the managers of the places don't make crap. And it's not like the industry doesn't brag about its money, that's all you hear about movies in the news, "record breaking weekend," "record opening," "biggest budget ever." I mean in a recession, a movie and dinner date is what? $50 to $100 depending on if you have drinks with dinner, you think the people working at the theater can afford that with their disposable income?
If I was working at a theater, I could possibly start boot legging, you can buy a decent recorder cheap and then if you had the connections to sell the movies you could easily make a lot more than you'd ever get at a theater. That's just simple economics. You want loyalty you have to fork out some more money. I'm not saying it's right to do it or anything but you get what you pay for and the movie biz is extremely top heavy paying people 10s of millions of dollars regularly where the people taking your tickets and cleaning up the theaters and actually showing the movies make squat.
Moreover, I don't know of a good optimizing AMD64 compiler that fully exploits the architecture. PGC might be okay, Metrowerks has a long history of building shitty compilers (my professional opionion) any compilers that anyone has experience with?
I think that you can probably get a lot more out of both chips. Most of those mac apps are compiled with GCC, which is great but xlC is a ton better on POWER and PowerPC.
They look about even in my book.
The original point is good, I still think more companies are blowing up because they are doing foolish things. Starting a company is very hard work and there is a lot of it. You either have to be a lot smarter than the competition or work a lot harder, no way around that and you're probably not that much smarter. The startup I'm with has busted our asses but it's looking positive, during the roughest parts I hated it but now looking back, it's the only way we've survived and done as well as we have.
Hmm? I don't understand what you're trying to say? The lack of binary drivers is the problem?
The whole time, being a Linux user and developer, I was talking about opensourcing this and that, there was so much opensource in BeOS to begin with, why not take the bull by the horns. Be used Linux as a host platform to develop beos. Be used GCC. Be carped driver designs, and an OS platform from GPL libre software. Nothing ever happened. I even wrote to the company and explained it, the response is that we don't want to help linux, we want to be Be. Now the community is doing this and they are still against Linux; their FAQ even mentions that OpenBeos on linux would be an extension to linux and that is somehow a bad thing.
Long story short, I've got no sour grapes, I don't care about the money, time, effort or anything else, I think some of the ideas behind beos are cool. What chaps me is the unwillingness to play ball and the simple lack of a techincal explanation as to what Linux or BSD kernels (which ones did you look at?) doesn't do that the be kernel needs. Are we talking new APIs? Are talking messaging queues? Latency isn't there (I call bullshit on this one, especially with 2.4 and now 2.6) what exactly is it? In the interview he even says outright that he hasn't gone very deep, pretty much just dismissed it.
Be's problem as a company and a community has always been lot's of talk with no beef and some awful fear of playing with others. "Pervasive threading this," "media OS that" what does that mean? Why is it good? You'll never get an answer with numbers, at best "it feels" will be said. Further, in specifics, what is it that you need the linux kernel to do and why is it easier to start from scratch rather than fix linux to do that? Even if it isn't rolled into mainline, look at ucLinux, rtLinux, and other "forks." I'm simply asking as an engineer, which problem space is bigger? Again, I wish them well and have no real sour grapes other than I really want a project like this to succeed and from the information presented to me from them they aren't making good engineering decisions and aren't making a plan for success. If it's simply an experiment and they want to do it all then say that, but they aren't saying that and that makes me think they either don't know or it's some cultural flaw and either way I don't think it is a good thing for their success.
I understand that it's an opinion piece but what's the point. Really? I can't say that I've been inundated with "Mac OSX is more secure" noise from a lot of Mac fan boys.
In fact other than a few free/libre software idealists I can't say that I really associate with any sort of fan boys, not OSX vs. Windows, not PS2 vs. XBox, none of that shit. We grew up, got jobs and when we're not geeking or working we're talking about our wives and kids or doing something not computer related..
Or in ebook? I'd love to have it with me all the time sans lugging the big book around. I'd gladly pay for the ebook.