Here in Greece protest do no more than stop traffic.
Scince when do you need a protest for that?;-)
Seriously, though, I guess that demonstations have a richer and more sucessfull tradition in most parts of europe than they have in the USA. Which isn't saying much.
However, this fight isn't over yet. Let's keep kicking ass. It not only helps keeping europe a saner place, maybe it someday also helps our american friends realize what they could achive if they would stop being nationalist pricks.
If you look at the last articles in the BSD section, there's been a lot of junk lately (like the gettext update). My guess is that they are up to something - maybe that's part of a wicked plan for the traditional premature announcement of the next FreeBSD release or something.
If you write software that violates a european patent and distribute it in europe (for example by putting it on a globally reachable web server), you can be sued. Not to mention that I'm quite sure that you are using software written by european developers that would certainly be affected. So stop being such a narrow-minded dork, if you will.
Why not teach people to write correct code instead.
Why not do both?
And BTW, what happens when your String class runs out of memory? (Yes, I've seen code which reads an entire file into a String....) So I guess it's better to segfault than risk buffer overrun?
Yes, in most cases, it is. Normally, I'd rather have a possible DoS than somebody writing in my stack.
The String types dynamically allocate memory...
This has little to do with the problem I was talking (well, at least thinking...) about. Of course, if you need to run in bounded space, dynamical allocation is not for you. Still, bounds checking would be nice.
malloc has some notable bugs in it - it often hangs when allocating numerous small chunks of memory; when it does, no amount of exception handling will bring control back to your program. Because of this, it's actually better to allocate a large chunk of memory at the outset and parcel it out as the program needs it, rather than running the risk of hanging the machine with a large number of calls to malloc.
Even without bugs, mallocing lots of small chunks tends to be rather slow - which is indeed something many programmers tend to forget, treating malloc as an essentially cost-free operation. I have actually seen C code that became a lot faster after using a garbage collector - the mark-and-sweep phase was less overhead than what was gained by making allocation to little more than a pointer increment.
When it comes down to it, security requires more thought than just using some nifty-yet-formally-incomplete classes.
Of course. I'd still claim that some programming environments make it easier to introduce critical bugs than others, but nothing will prevent a non-thinking coder from messing things up big time. Look at all the PHP guys, they don't have buffer overflows (except in the PHP interpreter itself, of course), but they still manage to keep all their nifty web forums a frequent topic on the security mailing lists.
strlcpy is 27 lines of portable C in the FreeBSD version, including K&R-style prototype, blank lines and comments. Hardly too much to include if autoconf tells you that it's missing, and well worth it - not because code using str(n?)cpy is inherently broken, but because it's just easier to work with.
Erm, you are aware that ECMA actually is a standards body, while the OMG is basically a private club of software vendors? And that few standards bodys do work just for fun?
Not that I'm all that fond of.NET, but that argument is pretty weak.
Wow. based solely on this logic, I am convinced we should [...] remove plugin capability from our web browsers (no more flash, ra, java, acrobot or others, please).
Nah, that's what we have to do because it's patented.
The call for standardization is not anti-innovation. It is about basic commonality of functions and consistent user experience. That's what Apple got right with the Mac early on, and MS caught onto after a while.
Funny how you try to enforce your "call for standardization" with references to two incompatible, competing UIs.
The whole multiple desktop issue is only a problem if your task is to have "linux conquer the desktop". This is, IMHO, flawed thinking - Linux will not succeed on the desktop, because it doesn't even have a GUI. Or a shell, for that matter. But you can build something with Linux that has.
There are multiple desktop systems, and some of then can use Linux as their basic infrastructure - Gnome and KDE can, Windows and OS X are standalone solutions. This is the level that matters for desktop users, the UI and the apps, not kernels and hardware drivers. If anything, Gnome and KDE will conquer the desktop, not Linux.
The nice thing about the Linux-based (rather, Unix-based) Desktops is that, once you decided for one of them, you can still use that one app that is only available for the other, which is not easily possible if you had chosen Windows or OS X.
Because it is not possible to write an app that integrates equally well in both desktops. And this is not just about themes, but about lots of little things like button order, placement of menu items, instant-apply versus explicit-apply in preferences dialogs. Such things can drive users mad if inconsistent, and you cannot be consistent with both Gnome and KDE.
Given that the win32 client obviously was written by a 13 year old hax0r using VB in 1996, this can only be a win. On the other hand, WebAccess or what it's called manages to mimic the usability of the native client closely, the main difference being even poorer performance.
Let's just hope they let the Ximian guys take care of it. Evolution's user interface is braindead on it's own, mostly due to religiously following MS Outlook, but at least there is a fair chance of getting work done with it.
Is there something more difficult about running Java on BSD than on another OS like Linux?
Yes, there is. BSD isn't hyped, and Sun doesn't sell computers with BSD preinstalled. That means that it isn't part of their definition of "everywhere" (as in "write once, run everywhere"), and they won't do more than they absolutely have to to support it.
Oh, you meant technical reasons? Java works fine on BSD, and has for a long time. We are talking about licensing issues here.
Good thing that there is finally a tutorial explaining this highly obscure part of advanced Linux administration. This is really good news for all us nerds, and surely matters a lot.
I mean, come on, has someone hacked hemos' account and uses it to destroy the/. community by boring it to death? What will the next story be, "GNU Hurd still not production ready"?
RedHats early stuff is not ready for prime time, usually that takes until the.2 release
Redhat will not be releasing point versions for the consumer versions
Dunno about Linux ACLs, but the FreeBSD ones follow POSIX.1e rather closely, and Solaris seems heavily inspired by them, even if it's not API compatible. Sounds like a Unix thing to me, even if the standardization effort has been canceled (the downloadable versions of POSIX.1e have "Withdrawn Draft" printed all over them).
It's really not much more than a generalization of the user/group/other read/write/execute matrix. How you implement it, using extended attributes or by extending the "native" permission implementation, doesn't really matter much, from a user perspective.
What BSDPAN actually does seems to be the opposite of this. It's not about the perl modules in the ports tree. The trick is that modules installed with the plain old CPAN module rather than the FreeBSD-specific tools get registered as FreeBSD packages nevertheless, so that you can uninstall them with the pkg*-tools, inspect them with pkg_info etc.
Wasn't it actually the other way around? Sun, and other Unix vendors, "unbundling" their compilers from the OSes, thus suddenly driving up GNU sales, making the project more widely recognized as it ever was before?
GCC perhaps wouldn't be an adequate (and sometimes better) alternative if the proprietary world hadn't driven itself out of the market
And once they have proven that samba is actually built on their IP, it should be immediatly obvious that Microsoft (and hence all Windows users) owe them big time. It is clearly impossible that some hobbyist company that builds basic interpreters in some garage manages to build an enterprise-class implementation of the SMB protocol in just a few decades without stealing from them.
Don't be selfish. Most of the world doesn't really care about californian budget deficits, but a cute smart chick talking about coding in Emacs? If that's not news for nerds, what is?
Slashdot Mirror
Seriously, though, I guess that demonstations have a richer and more sucessfull tradition in most parts of europe than they have in the USA. Which isn't saying much.
However, this fight isn't over yet. Let's keep kicking ass. It not only helps keeping europe a saner place, maybe it someday also helps our american friends realize what they could achive if they would stop being nationalist pricks.
If you look at the last articles in the BSD section, there's been a lot of junk lately (like the gettext update). My guess is that they are up to something - maybe that's part of a wicked plan for the traditional premature announcement of the next FreeBSD release or something.
If you write software that violates a european patent and distribute it in europe (for example by putting it on a globally reachable web server), you can be sued. Not to mention that I'm quite sure that you are using software written by european developers that would certainly be affected. So stop being such a narrow-minded dork, if you will.
A kernel that depends on a specific compiler is worthless.
strlcpy is 27 lines of portable C in the FreeBSD version, including K&R-style prototype, blank lines and comments. Hardly too much to include if autoconf tells you that it's missing, and well worth it - not because code using str(n?)cpy is inherently broken, but because it's just easier to work with.
Not that I'm all that fond of .NET, but that argument is pretty weak.
After that, maybe we can look into programming languages that actually have a string type, and don't tend to make every bug exploitable by default.
The whole multiple desktop issue is only a problem if your task is to have "linux conquer the desktop". This is, IMHO, flawed thinking - Linux will not succeed on the desktop, because it doesn't even have a GUI. Or a shell, for that matter. But you can build something with Linux that has.
There are multiple desktop systems, and some of then can use Linux as their basic infrastructure - Gnome and KDE can, Windows and OS X are standalone solutions. This is the level that matters for desktop users, the UI and the apps, not kernels and hardware drivers. If anything, Gnome and KDE will conquer the desktop, not Linux.
The nice thing about the Linux-based (rather, Unix-based) Desktops is that, once you decided for one of them, you can still use that one app that is only available for the other, which is not easily possible if you had chosen Windows or OS X.
Because it is not possible to write an app that integrates equally well in both desktops. And this is not just about themes, but about lots of little things like button order, placement of menu items, instant-apply versus explicit-apply in preferences dialogs. Such things can drive users mad if inconsistent, and you cannot be consistent with both Gnome and KDE.
Write long, pointless articles and have them mentioned on the slashdot front page.
Let's wait how long it takes that other office suite vendor to see the light. After all, they are an OASIS member themselves...
Let's just hope they let the Ximian guys take care of it. Evolution's user interface is braindead on it's own, mostly due to religiously following MS Outlook, but at least there is a fair chance of getting work done with it.
Oh, you meant technical reasons? Java works fine on BSD, and has for a long time. We are talking about licensing issues here.
I mean, come on, has someone hacked hemos' account and uses it to destroy the /. community by boring it to death? What will the next story be, "GNU Hurd still not production ready"?
It's really not much more than a generalization of the user/group/other read/write/execute matrix. How you implement it, using extended attributes or by extending the "native" permission implementation, doesn't really matter much, from a user perspective.
What BSDPAN actually does seems to be the opposite of this. It's not about the perl modules in the ports tree. The trick is that modules installed with the plain old CPAN module rather than the FreeBSD-specific tools get registered as FreeBSD packages nevertheless, so that you can uninstall them with the pkg*-tools, inspect them with pkg_info etc.
Because boycotting a company that doesn't have any customers anyway is pretty pointless?
GCC perhaps wouldn't be an adequate (and sometimes better) alternative if the proprietary world hadn't driven itself out of the market
And once they have proven that samba is actually built on their IP, it should be immediatly obvious that Microsoft (and hence all Windows users) owe them big time. It is clearly impossible that some hobbyist company that builds basic interpreters in some garage manages to build an enterprise-class implementation of the SMB protocol in just a few decades without stealing from them.
Don't be selfish. Most of the world doesn't really care about californian budget deficits, but a cute smart chick talking about coding in Emacs? If that's not news for nerds, what is?