Well, Java has 'goto' as a keyword, but it's unimplemented. Does that make it a success and a failure at the same time? Or is this like a quantum thing where we have to wait and see if it gets implemented to make the actual call as to its success?
Check the samba lists. It's already been fixed and the Debian team should be sending a patched version of samba to their repos for downstream distros either last night or some time today. It's already been rolled in to 3.0.30, IIRC.
I call dibs on a databased backed file system being the next casualty of slippage! I'll target it for being yanked six months from now. Seriously, is Windows 7 supposed to have the new FS that they dropped from Vista?
I don't necessarily take issue with what you've said (I've got you on my friend list, so I'm fairly sure that your one of the professionals on this site whose insight I love to read... I'm a software development major in college, so I usually add programmers to my friends list when I genuinely value their insights...), but I would like to point out that I've seen another approach to your first point about locking busses. The Linux kernel, IIRC, does a sideways and backwards cache flush to RAM before masking IRQs on an SMP system. I think it defers top half of interrupts to another CPU and doesn't queue the bottom halves. I might be mistaken on that, though. It then 'takes over' the CPU for the process/thread, and when it's done, it flushes all the caches once again.
But, as you said, the lock doesn't require a bus lock. Please correct me if I'm wrong on this, it's been a few months since I've read that piece of code and I'm a little hazy on the exact details.
As usual, this will create a support nightmare (for paying customers), and will be cracked in 4 months at most...
[...] Four months? I find your lack of faith disturbing! What was CSS broke in, three hours with three lines of recursive code?
No, this it's still just plugins, there's just a lot of them. It's just like a Linux distro these days. Sure, you could roll your own, but your usage will probably fall in to a certain category where there is a software (plugin) stack that everyone else with that usage pattern will have. So, it's easier to just hit the ground running with a preconfigured stack. Also, as with Linux distros, each distro has its own automated, dependency checking and gathering, interface. They also tell you when there are updates, etc., which is also nice.
Have you tried Yoxos? I've yet to try Photran, but haven't needed anything other than yoxos or an update site since about late 3.1/early 3.2. Does it do dependency resolution for plugins?
I agree with your assessment, and I really do like eclipse. The bloat isn't too bad when you consider the trade-off of flexibility; on any given day, being a software development major with an internship, I may be using any one or more of 4 OSes, and any number of flavors thereof. I may also be using any one of several desktops between school, home, and work. Furthermore, I may be using any number of languages.
Eclipse is the only IDE that I've found that can work across all these scenarios, and leave me with the same IDE across multiple languages. I don't have to worry about remembering the layout of multiple IDEs for each language or OS, and that makes me more productive. I install the plugins that I need (YOXOS, FTW!), and I can drop the eclipse directory on a network share, USB drive, or live CD and have the same environment everywhere I go. Every computer has a JRE installed these days. Also, each summer they do an incredible job of releasing multiple projects on the same day. The built in debugger is great, too. I've yet to find a better way to debug multi-threaded apps. Finally, you can specify, at launch, the memory parameters for the IDE via the normal JRE flags (-xmms, -xmlimit, etc.) if you aren't on such a beefy machine. But then again, if you're developing and debugging any language 'higher' than c/c++ these days, your sanity will depend on having a fairly beefy machine. Especially if you want to have firefox open on one screen and your IDE open in another (although, you can open firefox in Eclipse if you haven't the extra screen real estate).
It's unfortunate that the in crowd, armed with mostly FUD and occasional actual arguments, has decided that Eclipse is 'teh sux0rz'. I've yet to find many people who can put up much of an argument against Eclipse that doesn't center around; "Java is slow" (1996 wants their troll back, modern JITs are nearly as fast as native machine code), "it's ugly" (right, does it work?), "it uses too much memory" (ok, have you bothered to change your JRE memory settings?), "it's a huge download" (without JRE the base download is less than 100 MB), "dependency chasing sucks" (true, have you tried YOXOS?), "I'd prefer emacs" (I prefer vi, but you won't catch me writing or debugging a high level language in it). To each his own, but Eclipse is a great IDE if you give it a shot.
Great suggestion on playing with servers. I'd just like to add that if you want to actually understand what you're administrating, you should probably start with a vanilla Slackware install. You'll have to build from the ground up and understand how each part of the system interacts with the rest. It'll also "cure" any "fear" of using a command line. Because, let's be honest, usually when things go Very Bad, SSH may be the only interface you'll have, even if it's a headless box in your bedroom closet. Unless you like lugging around that old 17" CRT, have an extra LCD lying around, or don't mind the security risks associated with almost all the alternatives to SSH. Also, once you're comfortable with a CLI, you'll be able to solve problems so much more quickly than using a GUI or web interface.
Not that I have anything against Webmin (I actually love it for routine maintenance), but when I'm putting out a fire, I don't want to hunt around the numerous modules to find the correct knobs and buttons; I want to go straight to the problem and nail the sucker down as quickly as possible and I've found the command line the best way to do this. Especially on a thrashing, very unhappy box, when every other interface is either down or effectively inoperable because of the overhead of the service running it.
Also, you've hit the nail on the head about users who "think they know what they want". If they knew what they want, they'd already have done it themselves. Unless they come to you telling you what they're going to set up and trying to size up your options for it, they will be under the assumption that you're going to set it up for them. The people who really know what they want will come to you and say, "I'm going to set up a PHP-5, MySQL and apache stack for a site with X expected traffic and Y expected storage. I'll need Z throughput with A IOP/s. What package do you have that fits this setup, and what is your SLA like?" Everyone else will ask if you do "AJAX-y web two point oh enterprise stuff".
I just finished finals, and I'm working my internship during the summer; Monday - Friday, 9-5. I've heard that there is a contest to be had here? My proposal for the Google SOC was rejected and I need something to do for 8 hours a day. Where do I sign up, and where's the pizza? P.S. I'm armed with 10 mbit fiber here at work! Engarde.
I agree. Also, how many more would like to respond, but are stuck in red tape, or a form that needs to be signed off in triplicate is sitting in a pile on someone's desk?
I don't know if you ever used the site back in the day (they've changed it now), but I really like county paintball's javascript 'folder' layout in the left pane of the window. It was a hierarchy of 'folders', windows style, that you could expand by hitting a '+' icon next to the folder icon, and you could load the contents of any folder level by clicking on the folder itself. If you were done with a section, just collapse the top parent folder and everything was collapsed back in to the parent. The only page loads were if you wanted to see the gear in a folder. It was subtle, elegant, and didn't require loading a new window or refreshing the entire thing every time you clicked a link. It didn't require a plugin, either.
Paintball gear sites are especially difficult, because almost every section has to be broken up by gun manufacturer; a bad design is unbearable. If I want a barrel, bolt, and CO2 tank, I have to navigate to the barrel section, then the barrel manufacturer, then the version of that barrel for my gun. Then trace back and do the same for my bolt, and finally trace back and go to a generic section for tanks. I've left paintball sites before because the navigation was bad. IMHO, the correct navigation for a paintball site is a generic category for each item, broken down by part manufacturer, and a drop down list for gun manufacturer when ordering, with a second drop down for color or other attributes like barrel length, etc. If I want a black, 14" J&J ceramic barrel for a Spyder or Piranha (they have the same threading), I should only have to navigate to a J&J ceramic section under barrels. And that should require, at most, exactly one page reload. If its any consolation, I won't be spending my money at a paintball site that makes browsing a chore, so your former employer isn't seeing my cash.
Right. Routines. Not invoicing software that has the business logic, form, and database access rolled in to a single blob. Routines are fine. Single tiering a decidedly multi-tiered application is not.
[...]Corporate america is riddled with these kind of monsters causing IT people to ball up under their desks and cry through the night.
I was happy when they removed VBA because it stopped that nightmare. My Access nightmare has me slowly rocking back and fourth in a ball under my desk as we speak; it's been 'upgraded' since Office '97. *silently weeps, humming the theme of 'Friends', while balled up and slowly rocking back and fourth under his desk*
I think the VBA engine is somewhat tightly tied to the win32 API and system DLLs. Most likely having a single engine would have been a complete mess as its a "middle layer" component, and has to interface the system and office beneath it and the window manager above it.
Sometimes it's easier to just branch the code base than try to maintain too many interfaces and libraries with their own edge cases and corner cases. What would they do if two obscure bugs intersected such that the semantics of fixing one would necessarily break the other? They'd have to kludge around it and then maintain that kludge for the product life, and perhaps into other products and their lifetimes. This was probably a wise move, IMHO. Logic is more flexible than the code that supports it. I could be completely wrong about this, of course. Take it with a grain of salt.
Which department were you in, if you don't mind saying? I mean, were you working with Windows or one of the 'core' technologies, or the games studio? I think that some segments of MS have been maturing while the 'core' components (OS and Office) have been falling behind. This is, of course, from an outsiders perspective... but you can see how Visual Studio has been getting better and better while Vista turned out to be... well, Vista. The Open Source labs over there seem to be picking up a bit, too.
Just wondering... did your program interface a database at all? You should see the regressions with DAO/ADO/ODBC/JET/Etc. Now all you've got is ADO.NET, and from what I've seen the calls aren't the same as the calls for the pre-.net APIs.
Slashdot Mirror
Well, Java has 'goto' as a keyword, but it's unimplemented. Does that make it a success and a failure at the same time? Or is this like a quantum thing where we have to wait and see if it gets implemented to make the actual call as to its success?
I'll check them for you, free of charge... what did you say their IPs were? :)
Check the samba lists. It's already been fixed and the Debian team should be sending a patched version of samba to their repos for downstream distros either last night or some time today. It's already been rolled in to 3.0.30, IIRC.
That's why you leave it completely open and call your wireless network "honeypot" ;)
I call dibs on a databased backed file system being the next casualty of slippage! I'll target it for being yanked six months from now. Seriously, is Windows 7 supposed to have the new FS that they dropped from Vista?
I don't necessarily take issue with what you've said (I've got you on my friend list, so I'm fairly sure that your one of the professionals on this site whose insight I love to read... I'm a software development major in college, so I usually add programmers to my friends list when I genuinely value their insights...), but I would like to point out that I've seen another approach to your first point about locking busses. The Linux kernel, IIRC, does a sideways and backwards cache flush to RAM before masking IRQs on an SMP system. I think it defers top half of interrupts to another CPU and doesn't queue the bottom halves. I might be mistaken on that, though. It then 'takes over' the CPU for the process/thread, and when it's done, it flushes all the caches once again.
But, as you said, the lock doesn't require a bus lock. Please correct me if I'm wrong on this, it's been a few months since I've read that piece of code and I'm a little hazy on the exact details.
You mean, you're remaking Slackware? *ducks*
No, this it's still just plugins, there's just a lot of them. It's just like a Linux distro these days. Sure, you could roll your own, but your usage will probably fall in to a certain category where there is a software (plugin) stack that everyone else with that usage pattern will have. So, it's easier to just hit the ground running with a preconfigured stack. Also, as with Linux distros, each distro has its own automated, dependency checking and gathering, interface. They also tell you when there are updates, etc., which is also nice.
Sorry, I don't think I was clear in my last post; Emonic is a third party plugin. There are also a great number of other plugins.
Emonic, and there are a number of SQL server plugins.
Have you tried Yoxos? I've yet to try Photran, but haven't needed anything other than yoxos or an update site since about late 3.1/early 3.2. Does it do dependency resolution for plugins?
I agree with your assessment, and I really do like eclipse. The bloat isn't too bad when you consider the trade-off of flexibility; on any given day, being a software development major with an internship, I may be using any one or more of 4 OSes, and any number of flavors thereof. I may also be using any one of several desktops between school, home, and work. Furthermore, I may be using any number of languages.
Eclipse is the only IDE that I've found that can work across all these scenarios, and leave me with the same IDE across multiple languages. I don't have to worry about remembering the layout of multiple IDEs for each language or OS, and that makes me more productive. I install the plugins that I need (YOXOS, FTW!), and I can drop the eclipse directory on a network share, USB drive, or live CD and have the same environment everywhere I go. Every computer has a JRE installed these days. Also, each summer they do an incredible job of releasing multiple projects on the same day. The built in debugger is great, too. I've yet to find a better way to debug multi-threaded apps. Finally, you can specify, at launch, the memory parameters for the IDE via the normal JRE flags (-xmms, -xmlimit, etc.) if you aren't on such a beefy machine. But then again, if you're developing and debugging any language 'higher' than c/c++ these days, your sanity will depend on having a fairly beefy machine. Especially if you want to have firefox open on one screen and your IDE open in another (although, you can open firefox in Eclipse if you haven't the extra screen real estate).
It's unfortunate that the in crowd, armed with mostly FUD and occasional actual arguments, has decided that Eclipse is 'teh sux0rz'. I've yet to find many people who can put up much of an argument against Eclipse that doesn't center around; "Java is slow" (1996 wants their troll back, modern JITs are nearly as fast as native machine code), "it's ugly" (right, does it work?), "it uses too much memory" (ok, have you bothered to change your JRE memory settings?), "it's a huge download" (without JRE the base download is less than 100 MB), "dependency chasing sucks" (true, have you tried YOXOS?), "I'd prefer emacs" (I prefer vi, but you won't catch me writing or debugging a high level language in it). To each his own, but Eclipse is a great IDE if you give it a shot.
Great suggestion on playing with servers. I'd just like to add that if you want to actually understand what you're administrating, you should probably start with a vanilla Slackware install. You'll have to build from the ground up and understand how each part of the system interacts with the rest. It'll also "cure" any "fear" of using a command line. Because, let's be honest, usually when things go Very Bad, SSH may be the only interface you'll have, even if it's a headless box in your bedroom closet. Unless you like lugging around that old 17" CRT, have an extra LCD lying around, or don't mind the security risks associated with almost all the alternatives to SSH. Also, once you're comfortable with a CLI, you'll be able to solve problems so much more quickly than using a GUI or web interface.
Not that I have anything against Webmin (I actually love it for routine maintenance), but when I'm putting out a fire, I don't want to hunt around the numerous modules to find the correct knobs and buttons; I want to go straight to the problem and nail the sucker down as quickly as possible and I've found the command line the best way to do this. Especially on a thrashing, very unhappy box, when every other interface is either down or effectively inoperable because of the overhead of the service running it.
Also, you've hit the nail on the head about users who "think they know what they want". If they knew what they want, they'd already have done it themselves. Unless they come to you telling you what they're going to set up and trying to size up your options for it, they will be under the assumption that you're going to set it up for them. The people who really know what they want will come to you and say, "I'm going to set up a PHP-5, MySQL and apache stack for a site with X expected traffic and Y expected storage. I'll need Z throughput with A IOP/s. What package do you have that fits this setup, and what is your SLA like?" Everyone else will ask if you do "AJAX-y web two point oh enterprise stuff".
I just finished finals, and I'm working my internship during the summer; Monday - Friday, 9-5. I've heard that there is a contest to be had here? My proposal for the Google SOC was rejected and I need something to do for 8 hours a day. Where do I sign up, and where's the pizza? P.S. I'm armed with 10 mbit fiber here at work! Engarde.
I agree. Also, how many more would like to respond, but are stuck in red tape, or a form that needs to be signed off in triplicate is sitting in a pile on someone's desk?
I don't know if you ever used the site back in the day (they've changed it now), but I really like county paintball's javascript 'folder' layout in the left pane of the window. It was a hierarchy of 'folders', windows style, that you could expand by hitting a '+' icon next to the folder icon, and you could load the contents of any folder level by clicking on the folder itself. If you were done with a section, just collapse the top parent folder and everything was collapsed back in to the parent. The only page loads were if you wanted to see the gear in a folder. It was subtle, elegant, and didn't require loading a new window or refreshing the entire thing every time you clicked a link. It didn't require a plugin, either.
Paintball gear sites are especially difficult, because almost every section has to be broken up by gun manufacturer; a bad design is unbearable. If I want a barrel, bolt, and CO2 tank, I have to navigate to the barrel section, then the barrel manufacturer, then the version of that barrel for my gun. Then trace back and do the same for my bolt, and finally trace back and go to a generic section for tanks. I've left paintball sites before because the navigation was bad. IMHO, the correct navigation for a paintball site is a generic category for each item, broken down by part manufacturer, and a drop down list for gun manufacturer when ordering, with a second drop down for color or other attributes like barrel length, etc. If I want a black, 14" J&J ceramic barrel for a Spyder or Piranha (they have the same threading), I should only have to navigate to a J&J ceramic section under barrels. And that should require, at most, exactly one page reload. If its any consolation, I won't be spending my money at a paintball site that makes browsing a chore, so your former employer isn't seeing my cash.
Right. Routines. Not invoicing software that has the business logic, form, and database access rolled in to a single blob. Routines are fine. Single tiering a decidedly multi-tiered application is not.
*silently weeps, humming the theme of 'Friends', while balled up and slowly rocking back and fourth under his desk*
I think the VBA engine is somewhat tightly tied to the win32 API and system DLLs. Most likely having a single engine would have been a complete mess as its a "middle layer" component, and has to interface the system and office beneath it and the window manager above it.
Sometimes it's easier to just branch the code base than try to maintain too many interfaces and libraries with their own edge cases and corner cases. What would they do if two obscure bugs intersected such that the semantics of fixing one would necessarily break the other? They'd have to kludge around it and then maintain that kludge for the product life, and perhaps into other products and their lifetimes. This was probably a wise move, IMHO. Logic is more flexible than the code that supports it. I could be completely wrong about this, of course. Take it with a grain of salt.
Which department were you in, if you don't mind saying? I mean, were you working with Windows or one of the 'core' technologies, or the games studio? I think that some segments of MS have been maturing while the 'core' components (OS and Office) have been falling behind. This is, of course, from an outsiders perspective... but you can see how Visual Studio has been getting better and better while Vista turned out to be... well, Vista. The Open Source labs over there seem to be picking up a bit, too.
Just wondering... did your program interface a database at all? You should see the regressions with DAO/ADO/ODBC/JET/Etc. Now all you've got is ADO.NET, and from what I've seen the calls aren't the same as the calls for the pre-.net APIs.
touche.
As a general rule of thumb, don't trust the ones that contact you. Be weary of the ones you contact.