Blame gcc. On my Ultra 10 running 64-bit Solaris7, hello world compiled with DevStudio comes out to 6104 bytes, and with gcc comes out to 24,368 bytes. gcc compiling with any amount of optimizations shaved a whopping 16 bytes off the executable. DevStudio compiling with -xO5 -xspace brought it down to 1999 bytes.
Try a SunRay1 (aka Corona in many circles). Thin as it gets, they're a framebuffer on ethernet, for the most part. A cheap dumb graphical terminal, your X session runs on the big monster server. One big expensive machine, but only one to manage. Talk about going full-circle, eh? They do have some interesting features. Stick a smartcard into one and log in, and your session follows the card. Yank the card out, and it goes to the login screen. Stick it into another corona box, and your session comes back up. Even the mouse is in the same place. The hardware is all USB, so you can use your favorite USB peripherals, including printers and scanners (it locates and adds them, presumably via Jini). Anyhow, you wouldn't run coronas over a WAN, but then again, ultra-thin clients aren't necessarily the best choice on a WAN either.
BTW, just as a disclosure, I do work for Sun. I personally don't think SunRays are the ultimate solution to desktops, but they're the niftiest dumb terminals I've seen yet.
MOO is by far not a very featureful language in terms of library code. It has no native interface, it has no graphics libs, it doesn't even handle I/O very well. However, what it does have is a very consistent and sensible syntax using if/endif, for/endfor, while/endwhile, try/endtry, and a pretty-printer that lets others read your code in an indent style that's readable but doesn't force you to use it when entering the code (I wish python had figured that out). String and list slicing use identical syntax (hint hint perl), lists can be created and nested as literals and spliced with a single operator (another hint, perl. python, how about a splice operator?)
But what I love most about MOO is the flexibility. As an artifact of the way the MOO command parser was built, methods on objects can have aliases and wildcard endings. This is poor-man's pattern matching and meta-object protocol. Not as ultimately flexible as python (and perl if you really dig into the guts) but intuitive to grasp. You can call methods as a string expression, and it will search for the proper method, matching against aliases and wildcards. I've written some amazing funky dispatch tricks with this.
Any language can do this trick, python is pretty close to it and includes even more features than MOO (like multiple inheritance), and java has niftiness like anonymous classes (java has several scriptable variants now). But what really shines about MOO for me is that the write/run cycle is practically zero. I can have a MOO method in an editor window, make a change to it, and the change is there. I am hacking on a running system, there is no script to invoke, there is no explicit compile command (well there is, the core just hides it very well). I change a line of code, and the whole database of code has its behavior changed as intended (well, hopefully:)
MOO is ubiquitously persistent. When I create an object, there are no explicit semantics to "pickle" and "unpickle" it. It's just there, it's live, it's always there as long as the database is running.
Finally, add multi-user protection into the equation. Every persistent resource has an owner, including methods, and methods always run with the permissions of their creator, and that's on a per-activation basis. Call a method owned by someone else, it runs with its owner's permission. Only the superusers (wizards) can set the permissions otherwise. This means a trojan horse program isn't possible, because it cannot run with your permissions. It could call an improperly written method that that could mess you up, but it wouldn't have required you to run it in the first place. I am seeing much movement toward persistent object databases, but I have yet to see one that takes multi-user protection seriously I've seen Perl and Python both try it, but it's laughably light security. You write an execution monitor that can potentially be modified by code it's meant to monitor, and I don't think I have to tell you what that means to security.
Give me an industrial-strength language with a transparent write/compile/run cycle, a persistent DB, and bulletproof execute-as-owner permissions, and you've got a convert. Till then, I hack in "standalone" languages for work, but I'll stick with MOO for the joy of hacking it brings.
> I'm sure VB is hot for business apps. But I can't say I care. What about real-world apps
Since you've no doubt been duly flamed over the bogus distinction between "business" and "real world" apps, I won't visit it. I'd just like to register my opinion (okay, pontificate) on what a "real-world" app is.
Real world is not when your entire company has a need, goes to development, draws up requirements, negotiates price, goes through develop, test, deploy, test for real, revise, etc. Real world is when a department head has, say, an employee database like schedule times, for example, and wants it popped up on a web page or viewable in some quick tool they can pop up on their desktop. They go to the department's local programmer-dude (which I am in my department) without an actual developer title (usually a tech/admin) and say "hey can you do this?". Tech bangs out some perl or VB or shell script or excel macros, and there ya go, that work for you? Good, problem solved.
Real world is ad hoc, and VB lends itself to ad hoc solutions. I would consider software engineering to be necessarily several levels removed from this Real World, in order that the problem space becomes their world for an extended period. That's when you have systems programming languages like C++ or Java (yes it's the systems language of the Java platform).
Personally I don't think VB is ad-hoc ENOUGH, and its greatest weakness is that it only manages to do a half-ass job at being a quick-and-dirty prototyping system and being enterprise class, by trying to be both.
> WOMEN WANT SEX JUST AS MUCH AS MEN DO, just not with anybody (unlike men).
Best as I can summarize, from my very much outside perspective, this is quite true; However, after going through a lifetime of being patronized and objectified, most women tend to want meaningful sexual relations. After having shallow and crude sexual innuendo and gestures -- and often intercourse itself -- pushed on you for years and years, you'd grow pretty weary of sex for its own sake too. It becomes like the trendy song on the radio they just won't stop playing: After a while you get to hate the whole genre. This is a portrait of an extreme, but just ask any woman friend where inbetween she falls.
One part dry humor, ten parts asinine, a hundred parts yawn. I'll probably be single for the rest of my life because I don't relate to people, but I'd rather be that than... I don't have the words. The author ever thought of women as people? Oh wait, I guess he doesn't have to, because he's married now, and is guaranteed to have her for life.
AHAHAHAHAHAHAHAHAAAAAAaaaaa
You're in for some bitter resentment down the line, boy.
Re:Gartner amazes me with correctness, for once
on
Gartner Slams Linux
·
· Score: 2
>I don't like NT either, but ini files should only >exist in WINNT for two reasons:
3. Portable applications. Where you just drag the directory to copy it. See, not everyone who lugs their laptop out into the field lives in this magical ubiquitously-networked world where they can just grab the installed program off the server and read the remote registry.
Oh just shoot me. I used.txt in an example when I did this. Now something I WOULD like to see the shell become is a bona-fide scriptable programming language that supports a genuine object model, and transactions. Imagine being able to undo anything you screwed up in a transaction.
Writing a shell script to do anything that gets close to this is a relatively advanced problem -- and I don't believe it's possible without requiring some escaping/quoting/substituting to get the asterixes through the shell intact.
Utterly preposterous.
for file in *.doc do mv $file ${file%.doc} ${file%.doc}.txt done
I won't claim for a minute that's accessable to Joe Sixpack, but it's a bloody far cry from an "advanced problem"
> Ok, not quite default since you have to start the telnet service but close.
I would consider it a security FEATURE if most linuxes shipped with every service in inetd.conf disabled, including telnet. Only enable the features you need. I find that with my dial-up linux station, I simply do not need to uncomment the telnetd line. I use ssh whenever I want to open the box up for a friend to get in and help me out.
And if it's anything like the telnet daemon in the resource kit, you can expect it to crash the moment you disconnect. Actually, I think maybe they got it right with NT5, they seem to have gotten many things right.
But look at that prompt: "C:\". Still using backslashes, still using drive letters. Can I even do something as simple as mount a filesystem in NT, or is that still something that takes some third-party GUI app to do?
> It's my understanding that, and I could be wrong, Unix allows you to be in only one group at a time.
You get partial credit. In SysV unixen, you can only belong to your primary group and one secondary group, which you must explicitly switch to with newgrp. BSD unixen consider you a member of any group you're added to all at once. However, barring ACL's, a file can only be owned by one group.
You look at the idea of security through MS tinted eyes. In the real world, you'll find that there is rarely a person by person security level needed. Rather a group by group security level.
Yes, and without ACL's, only one group can have only one single type of access to a file: ownership. Mind you, POSIX ACL's have been out for ages, and damn near EVERY SINGLE commercial unix implements them. Now if I could use netgroups in setfacl, I would be basking in comfort, but MS still has one up on that.
NTFS is nice. BFS is god. ext2fs is a rebadged FFS, which hasn't appreciably updated in over 10 years.
You can thank the slavish emulation of Motif's excreble file selector for the behavior of GTK's selector. KDE's file selector is just excellent, albeit a big *big* by default (which I love, laptop users hate). If it had a true file browser widget with true file objects (like Windows) then it would be perfect. Mmmm, I love being able to drag-n-drop files out of the file selector.
Windows' file picker would be nearly perfect if it didn't scroll HORIZONTALLY. Whose lame idea was that?
This is a problem admitted by Sun. It is not E that won't run Java, but Java doesn't conform to some of the specs for X ICCCM (enough C's?) window manager compliance. They are supposed to be fixing that soon.
If Java *crashes* E because E can't handle a malformed ICCCM hint, then E simply can't run Java, period. I've completely given up on Java development on Linux BTW. I'm tired of waiting for the stable version of the latest Java RSN. My latest kick is JPython (even though I'm not a huge fan of python), but I do all my hacking with it on my Solaris box at work (and play Homeworld on my windoze box at home).
> But really the thing that makes me laugh about it is the endless hours of debate that Linux zealots have had regarding why the Windows registry is incredibly sucky. > And then KDE goes and implements the Windows Registry.:)
I see no hypocrisy here. Uninformed flaming zealots have a knee-jerk reaction against the registry because it's part of Windows, and real coders like the KDE people implement it because they know better. The main problem with the registry is that it's become abused as a dumping ground. That doesn't make the database itself bad.
Re:KDE TWO Conference Sponsorship
on
KDE Looks Ahead
·
· Score: 2
> insert(mouth(money));
Shouldn't it be insert(mouth, money)? money as a parameter of the mouth() function is a little odd. Then again, money talks:)
Re:Fragmentation of KDE/GNOME components...
on
KDE Looks Ahead
·
· Score: 3
Sorry about the previous flame... bah, I've been on slashdot too long, I didn't even READ the rest of the post. Where did my attention span go... what was I looking for again?
Just redirect that flame to someone who does argue that XYZ is the One True IPC Mechanism...
I really wish we could delete or moderate down our own posts, just someone else moderate it on down at least, ok?
Re:Fragmentation of KDE/GNOME components...
on
KDE Looks Ahead
·
· Score: 1
I bet you also think vi is the only word processor anyone needs.
Pipes require you to define the message boundaries yourself, do not have any facility for type safety or return values, require synchronized access across threads, have limited size before they fill up and block, cannot be opened across multiple transports (on BSD, SysV unixen are much nicer about this).
Look, when I'm working with objects and methods, I want an IPC mechanism that supports, astonishingly enough, objects and methods. Without having to wrap my own marshalling and synchronization protocols around something as low-level as a pipe.
> Do you think those people ever imagined such things as our graphing calculators, which are tons smaller and do tons more with less energy? No. They had no clue about what was to come.
Sure they did. Most of them are still alive.
The futre of integrated electronics is the future of electronics itself... Integrated circuits will lead to such wonders as home computers--or at least terminals connected to a central computer--automatic controls for automobiles, and personal portable communications equipment. The electronic wristwatch needs only a display to be feasable today.
-- Gordon E. Moore, Electronics magazine, Apr 19, 1965
I don't get it. The ONLY difference between the two code fragments above was a keyword change. Why would we have to have a new keyword when we can simply detect a parallel operation? Why generate values of i if they aren't used? If the compiler can prove array[] is never used in your function, it'll just drop the loop entirely Can't get much more efficient than that. Functional languages, which can evaluate arguments to functions in any order (thus parallel), will often not bother to even run the loop until array[i] is needed in a fashion that can't be delayed. The best way to optimize code is to find ways to not run it at all.
Slashdot Mirror
Blame gcc. On my Ultra 10 running 64-bit Solaris7, hello world compiled with DevStudio comes out to 6104 bytes, and with gcc comes out to 24,368 bytes. gcc compiling with any amount of optimizations shaved a whopping 16 bytes off the executable. DevStudio compiling with -xO5 -xspace brought it down to 1999 bytes.
You get what you pay for.
Try a SunRay1 (aka Corona in many circles). Thin as it gets, they're a framebuffer on ethernet, for the most part. A cheap dumb graphical terminal, your X session runs on the big monster server. One big expensive machine, but only one to manage. Talk about going full-circle, eh? They do have some interesting features. Stick a smartcard into one and log in, and your session follows the card. Yank the card out, and it goes to the login screen. Stick it into another corona box, and your session comes back up. Even the mouse is in the same place. The hardware is all USB, so you can use your favorite USB peripherals, including printers and scanners (it locates and adds them, presumably via Jini). Anyhow, you wouldn't run coronas over a WAN, but then again, ultra-thin clients aren't necessarily the best choice on a WAN either.
BTW, just as a disclosure, I do work for Sun. I personally don't think SunRays are the ultimate solution to desktops, but they're the niftiest dumb terminals I've seen yet.
Specifically, MOO (Mud, Object Oriented).
:)
MOO is by far not a very featureful language in terms of library code. It has no native interface, it has no graphics libs, it doesn't even handle I/O very well. However, what it does have is a very consistent and sensible syntax using if/endif, for/endfor, while/endwhile, try/endtry, and a pretty-printer that lets others read your code in an indent style that's readable but doesn't force you to use it when entering the code (I wish python had figured that out). String and list slicing use identical syntax (hint hint perl), lists can be created and nested as literals and spliced with a single operator (another hint, perl. python, how about a splice operator?)
But what I love most about MOO is the flexibility. As an artifact of the way the MOO command parser was built, methods on objects can have aliases and wildcard endings. This is poor-man's pattern matching and meta-object protocol. Not as ultimately flexible as python (and perl if you really dig into the guts) but intuitive to grasp. You can call methods as a string expression, and it will search for the proper method, matching against aliases and wildcards. I've written some amazing funky dispatch tricks with this.
Any language can do this trick, python is pretty close to it and includes even more features than MOO (like multiple inheritance), and java has niftiness like anonymous classes (java has several scriptable variants now). But what really shines about MOO for me is that the write/run cycle is practically zero. I can have a MOO method in an editor window, make a change to it, and the change is there. I am hacking on a running system, there is no script to invoke, there is no explicit compile command (well there is, the core just hides it very well). I change a line of code, and the whole database of code has its behavior changed as intended (well, hopefully
MOO is ubiquitously persistent. When I create an object, there are no explicit semantics to "pickle" and "unpickle" it. It's just there, it's live, it's always there as long as the database is running.
Finally, add multi-user protection into the equation. Every persistent resource has an owner, including methods, and methods always run with the permissions of their creator, and that's on a per-activation basis. Call a method owned by someone else, it runs with its owner's permission. Only the superusers (wizards) can set the permissions otherwise. This means a trojan horse program isn't possible, because it cannot run with your permissions. It could call an improperly written method that that could mess you up, but it wouldn't have required you to run it in the first place. I am seeing much movement toward persistent object databases, but I have yet to see one that takes multi-user protection seriously I've seen Perl and Python both try it, but it's laughably light security. You write an execution monitor that can potentially be modified by code it's meant to monitor, and I don't think I have to tell you what that means to security.
Give me an industrial-strength language with a transparent write/compile/run cycle, a persistent DB, and bulletproof execute-as-owner permissions, and you've got a convert. Till then, I hack in "standalone" languages for work, but I'll stick with MOO for the joy of hacking it brings.
> I'm sure VB is hot for business apps. But I can't say I care. What about real-world apps
Since you've no doubt been duly flamed over the bogus distinction between "business" and "real world" apps, I won't visit it. I'd just like to register my opinion (okay, pontificate) on what a "real-world" app is.
Real world is not when your entire company has a need, goes to development, draws up requirements, negotiates price, goes through develop, test, deploy, test for real, revise, etc. Real world is when a department head has, say, an employee database like schedule times, for example, and wants it popped up on a web page or viewable in some quick tool they can pop up on their desktop. They go to the department's local programmer-dude (which I am in my department) without an actual developer title (usually a tech/admin) and say "hey can you do this?". Tech bangs out some perl or VB or shell script or excel macros, and there ya go, that work for you? Good, problem solved.
Real world is ad hoc, and VB lends itself to ad hoc solutions. I would consider software engineering to be necessarily several levels removed from this Real World, in order that the problem space becomes their world for an extended period. That's when you have systems programming languages like C++ or Java (yes it's the systems language of the Java platform).
Personally I don't think VB is ad-hoc ENOUGH, and its greatest weakness is that it only manages to do a half-ass job at being a quick-and-dirty prototyping system and being enterprise class, by trying to be both.
> WOMEN WANT SEX JUST AS MUCH AS MEN DO, just not with anybody (unlike men).
Best as I can summarize, from my very much outside perspective, this is quite true; However, after going through a lifetime of being patronized and objectified, most women tend to want meaningful sexual relations. After having shallow and crude sexual innuendo and gestures -- and often intercourse itself -- pushed on you for years and years, you'd grow pretty weary of sex for its own sake too. It becomes like the trendy song on the radio they just won't stop playing: After a while you get to hate the whole genre. This is a portrait of an extreme, but just ask any woman friend where inbetween she falls.
One part dry humor, ten parts asinine, a hundred parts yawn. I'll probably be single for the rest of my life because I don't relate to people, but I'd rather be that than ... I don't have the words. The author ever thought of women as people? Oh wait, I guess he doesn't have to, because he's married now, and is guaranteed to have her for life.
AHAHAHAHAHAHAHAHAAAAAAaaaaa
You're in for some bitter resentment down the line, boy.
>I don't like NT either, but ini files should only >exist in WINNT for two reasons:
>1. badly coded applications
>2. 16-bit applications
3. Portable applications. Where you just drag the directory to copy it. See, not everyone who lugs their laptop out into the field lives in this magical ubiquitously-networked world where they can just grab the installed program off the server and read the remote registry.
Welcome to the real world.
Oh just shoot me. I used .txt in an example when I did this. Now something I WOULD like to see the shell become is a bona-fide scriptable programming language that supports a genuine object model, and transactions. Imagine being able to undo anything you screwed up in a transaction.
Blah, I need to proofread. that should have been:
for file in *.doc
do
mv $file ${file%.doc}.txt
done
Utterly preposterous.
for file in *.doc
do
mv $file ${file%.doc} ${file%.doc}.txt
done
I won't claim for a minute that's accessable to Joe Sixpack, but it's a bloody far cry from an "advanced problem"
> Ok, not quite default since you have to start the telnet service but close.
I would consider it a security FEATURE if most linuxes shipped with every service in inetd.conf disabled, including telnet. Only enable the features you need. I find that with my dial-up linux station, I simply do not need to uncomment the telnetd line. I use ssh whenever I want to open the box up for a friend to get in and help me out.
And if it's anything like the telnet daemon in the resource kit, you can expect it to crash the moment you disconnect. Actually, I think maybe they got it right with NT5, they seem to have gotten many things right.
But look at that prompt: "C:\". Still using backslashes, still using drive letters. Can I even do something as simple as mount a filesystem in NT, or is that still something that takes some third-party GUI app to do?
> It's my understanding that, and I could be wrong, Unix allows you to be in only one group at a time.
You get partial credit. In SysV unixen, you can only belong to your primary group and one secondary group, which you must explicitly switch to with newgrp. BSD unixen consider you a member of any group you're added to all at once. However, barring ACL's, a file can only be owned by one group.
Yes, and without ACL's, only one group can have only one single type of access to a file: ownership. Mind you, POSIX ACL's have been out for ages, and damn near EVERY SINGLE commercial unix implements them. Now if I could use netgroups in setfacl, I would be basking in comfort, but MS still has one up on that.
NTFS is nice. BFS is god. ext2fs is a rebadged FFS, which hasn't appreciably updated in over 10 years.
> 1.There are no service packs for Linux
So 2.2.12 exists because 12 is a prettier number than 0? Jesus, nothing makes Linux look worse than people who can't be realistic about it.
> I am not a language lawyer. Just paid attention in my grammar courses.
I defy you to produce a cite where "the team have" is proper usage.
You can thank the slavish emulation of Motif's excreble file selector for the behavior of GTK's selector. KDE's file selector is just excellent, albeit a big *big* by default (which I love, laptop users hate). If it had a true file browser widget with true file objects (like Windows) then it would be perfect. Mmmm, I love being able to drag-n-drop files out of the file selector.
Windows' file picker would be nearly perfect if it didn't scroll HORIZONTALLY. Whose lame idea was that?
If Java *crashes* E because E can't handle a malformed ICCCM hint, then E simply can't run Java, period. I've completely given up on Java development on Linux BTW. I'm tired of waiting for the stable version of the latest Java RSN. My latest kick is JPython (even though I'm not a huge fan of python), but I do all my hacking with it on my Solaris box at work (and play Homeworld on my windoze box at home).
> But really the thing that makes me laugh about it is the endless hours of debate that Linux zealots have had regarding why the Windows registry is incredibly sucky. :)
> And then KDE goes and implements the Windows Registry.
I see no hypocrisy here. Uninformed flaming zealots have a knee-jerk reaction against the registry because it's part of Windows, and real coders like the KDE people implement it because they know better. The main problem with the registry is that it's become abused as a dumping ground. That doesn't make the database itself bad.
> insert(mouth(money));
:)
Shouldn't it be insert(mouth, money)? money as a parameter of the mouth() function is a little odd. Then again, money talks
Sorry about the previous flame... bah, I've been on slashdot too long, I didn't even READ the rest of the post. Where did my attention span go... what was I looking for again?
Just redirect that flame to someone who does argue that XYZ is the One True IPC Mechanism...
I really wish we could delete or moderate down our own posts, just someone else moderate it on down at least, ok?
I bet you also think vi is the only word processor anyone needs.
Pipes require you to define the message boundaries yourself, do not have any facility for type safety or return values, require synchronized access across threads, have limited size before they fill up and block, cannot be opened across multiple transports (on BSD, SysV unixen are much nicer about this).
Look, when I'm working with objects and methods, I want an IPC mechanism that supports, astonishingly enough, objects and methods. Without having to wrap my own marshalling and synchronization protocols around something as low-level as a pipe.
Sure they did. Most of them are still alive.
> Think to yourself, what is the biggest, most power-consuming thing a computer could ever do. Ever.
Equal the human brain.
> It will stop there
No. WE will stop there. They won't.
I don't get it. The ONLY difference between the two code fragments above was a keyword change. Why would we have to have a new keyword when we can simply detect a parallel operation? Why generate values of i if they aren't used? If the compiler can prove array[] is never used in your function, it'll just drop the loop entirely Can't get much more efficient than that. Functional languages, which can evaluate arguments to functions in any order (thus parallel), will often not bother to even run the loop until array[i] is needed in a fashion that can't be delayed. The best way to optimize code is to find ways to not run it at all.
I suggest thinking in languages other than C.