1. Home
  2. Categories
  3. Side Bar WTF
  4. Remember that post ages ago about Aptana Studio/Eclipse doing a DoS on my User folder?

Remember that post ages ago about Aptana Studio/Eclipse doing a DoS on my User folder?

  • Ben L.

    Page 3.0

    0
  • B

    @Ben L. said:

    @morbiuswilters said:
    @blakeyrat said:
    (assuming it's as easy to ask Linux "hey give me an event when this file changes, please buddy?" as it is Windows)

    It's relatively easy, but they'll never do it because "it's not the Unix way"it violates the principle of least surprise.


    FTFY

    Yeah... I'm not sure how y'all got on that exact topic, but nobody with a brain wants Unix to do that.



    Semi OT: did Edie Brickell ever make anything good after that first album, or was that pretty much it?

    0
  • ender

    @blakeyrat said:

    Apache could do this (assuming it's as easy to ask Linux "hey give me an event when this file changes, please buddy?" as it is Windows), they just didn't bother because they don't give a shit about making a good product.
    As I mentioned above, Apache can do that.
    @morbiuswilters said:
    Of course they neglect to realize it's going to take them 9 months to find a good Unix sysadmin and he's going to cost them $140k, plus bennies.
    Companies are stupid - I've got several clients that have no problems paying me 5-10 hours per month to keep the same old system running, where if they replaced it with a new system at the cost of 2-3 months' work, it'd then need maybe 1 hour of maintenance per month. However, since the budgets are separate, they keep paying me over and over to put out the fires (not that I mind too much).

    0
  • blakeyrat

    @Ben L. said:

    Sometimes, computer programs can do things but they choose not to. Why? Because it would violate the principle of least surprise.

    If I change a configuration option, the least surprise would be the change takes effect right away. The most surprise would be, "why the fuck is it still going to the wrong 404 page? I already set the correct one! What's wrong with this fucking thing!"

    So basically you're arguing against your own position.

    0
  • morbiuswilters

    @Ben L. said:

    @morbiuswilters said:
    @blakeyrat said:
    (assuming it's as easy to ask Linux "hey give me an event when this file changes, please buddy?" as it is Windows)

    It's relatively easy, but they'll never do it because "it's not the Unix way"it violates the principle of least surprise.


    FTFY

    I don't think you know what that means. "Least surprise" just means it doesn't do something unexpected. Automatically picking up config changes is only unexpected in Apache because you've become accustomed to it. Ideally, it should pick up config changes without need of an external command, but it doesn't because Unix was never designed to support it. inotify is a pretty recent addition to Linux, so software really doesn't take advantage of this feature. Even then, there are other problems with automatically picking up config changes, all due to Unix and the Unix Way:

    1. Apache config files have unpredictable behavior. There's no guarantee a file only modifies a single site, or that changes in one file aren't dependent on changes in other files. An inotify-based system wouldn't be able to know which order to process files in.

    2. Lack of discipline among Unix sysadmins. In theory, your changes should be first QA'd on staging hardware before being promoted to production and deployed to production metal using a tool like puppet or chef. But the dominant attitude in the Unix world is still "just edit the config files on the production machines with emacs". Automatically picking up changes would be a disaster here.

    3. The Unix file API is very, very basic. Since writes to files are not guaranteed to be atomic, it's quite possible Apache would pick up a config file in the middle of it being written. There's no real locking mechanism to prevent this, although you could check advisory locks, they're optional and nobody uses them so you'd never know if a file was currently being modified.

    0
  • C

    @morbiuswilters said:

    Automatically picking up config changes is only unexpected in Apache because you've become accustomed to it.
     

    That. I think I've been so conditioned into the "change/test/reload to deploy" cycle that it's become expected behaviour so I get caught out by similar-looking systems that behave differently.

    @morbiuswilters said:

    1) Apache config files have unpredictable behavior. There's no guarantee a file only modifies a single site, or that changes in one file aren't dependent on changes in other files.

    Not completely true - directives can be limited down to affect just that directory, or just files matching a pattern for just that site. But I know what you mean - someone amending a vhost config doesn't realise global impact by default, unless otherwise limited.

    @morbiuswilters said:

    2) Lack of discipline among Unix sysadmins.
    Organisational issue. This happens anywhere there's poor management (or poor change control).

    @morbiuswilters said:

    But the dominant attitude in the Unix world is still "just edit the config files on the production machines with emacs".

    IME I've found it (generally) to be the other way around - I've come across many windows admins who are loose cannons but some that are quite organised, as well as many crusty neckbeards that are cautious. I don't think it's a OS thing, I think it's an age/experience thing.

    @morbiuswilters said:

    Automatically picking up changes would be a disaster here.

    They'll only need to burn their fingers once. Similarly if this was the norm, people would be conditioned into working in that manner.

    @morbiuswilters said:

    3) The Unix file API is very, very basic.

    Yeah, that too. Trying to amend a setting on my UT server with the game up and running keeps throwing prompts that my changes have been overwritten.

    0
  • morbiuswilters

    @Cassidy said:

    Not completely true - directives can be limited down to affect just that directory, or just files matching a pattern for just that site. But I know what you mean - someone amending a vhost config doesn't realise global impact by default, unless otherwise limited.

    Directives can be limited, but they don't have to be. Let's say 2 modified config files were picked up by Apache--what order should it load them in? If file B adds a "Listen 443" line and file A has a "VirtualHost:443" section, obviously B must come before A. The only way Apache could "get it right" is to re-process every file, like it does when you do a reload. However, that introduces further problems--file changes won't occur simultaneously and if Apache is listening for file changes, how does it know if it should wait for more files to be changed before trying to reparse all of the configs? It doesn't. Hence, this would not work given Apache's config file structure.

    @Cassidy said:

    IME I've found it (generally) to be the other way around - I've come across many windows admins who are loose cannons but some that are quite organised, as well as many crusty neckbeards that are cautious. I don't think it's a OS thing, I think it's an age/experience thing.

    It's not even so much a lack of caution as it is best practices. On Unix, best practice still tends to be "manage it all by-hand" whereas automated management seems much more deeply-ingrained on the Windows side of things. I've dealt with numerous Unix sysadmins whose attitude towards puppet was "Why? It just slows me down." Or even if they "get it", they will still make small config file changes directly on the servers. When I ask them if they put it into puppet, the response is something like "Oh, it's only a small file and it wasn't already managed by puppet, so I didn't want to bother." My response is "So now if I try to launch a new web server, something is going to come up mis-configured and there will be a mad dash to figure out why." Their reply is "Oh, but I can just make that config file fix again. It's really easy to track down and I'll remember."

    Seriously, how often do you see Unix sysadmins actually test their changes on non-production hardware beforehand? Or who use a configuration management system like puppet/chef?

    0
  • C

    @morbiuswilters said:

    Seriously, how often do you see Unix sysadmins actually test their changes on non-production hardware beforehand? Or who use a configuration management system like puppet/chef?
     

    Bugger all, IME - but I think you deal with sysadmins that manage a large number of boxes. Most of those I've dealt with are teams of bods that manage a small number.@morbiuswilters said:

    Their reply is "Oh, but I can just make that config file fix again. It's really easy to track down and I'll remember."

    "I want that in writing that you're confessioning to awaiting for a fault to develop before you'll fix it is actually better than preventing the fault in the first place".

    $deity, some people are only still alive because it's illegal to kill them.

    What IS puppet like, and how many servers would you consider it a viable option to use? I've not heard of it.

    0
  • morbiuswilters

    @Cassidy said:

    Bugger all, IME - but I think you deal with sysadmins that manage a large number of boxes. Most of those I've dealt with are teams of bods that manage a small number.

    I've run across very few. Most Unix sysadmins are like "How are you able to single-handedly run hundreds of production servers when your primary job isn't even sysadmin, it's software engineer? I don't understand." And I'm like "No, you don't."

    @Cassidy said:

    $deity, some all people are only still alive because it's illegal Morbius is too busy to kill them.

    FTFY.

    @Cassidy said:

    What IS puppet like...

    It is good. Chef is also good. Both are ways of managing all configuration changes to a server. Puppet uses a declarative syntax, meaning statements are not executed based on their order in the file but instead you must explicitly establish relationships between resources. Chef uses an imperative syntax, meaning it executes statement straight-down-the-file, just like any other script. Each has its advantages and disadvantages, but I find that people are more confused by Puppet simply because they expect things to happen in a linear order.

    Either way, the goal is to be able to build any type of server you need from scratch. It obviously works best when you're dealing with lots of similar servers--if you have 300 web or hadoop servers, Puppet is a god-send.

    @Cassidy said:

    ...how many servers would you consider it a viable option to use?

    One. Seriously. It's got some learning curve and you have to have the discipline to put every change into Puppet/Chef and to test them out. It really works best with VMs because you're going to want to spin up and spin down instances to test, but you can use it for anything. But even if you only have a single department server that "does it all", you know that rebuilding it is going to be a pain should you ever lose configuration. And God forbid you need to replace it with a new server.

    That said, from a practical standpoint most people aren't going to invest the time in puppetizing a single server. I understand why, but I've come to believe it is always worth it because it makes you think about your configurations in a reproduceable, testable way and it forces you to document everything.

    0
  • C

    @morbiuswilters said:

    I understand why, but I've come to believe it is always worth it because it makes you think about your configurations in a reproduceable, testable way and it forces you to document everything.
     

    I used my home box as a testbed for my "production" server and copied working configs from one to the other once I was done. Puppet or Chef would have probably helped out in that case.

    The idea of dropping configs onto some repo so they can be deployed onto a VM interests me. A quick yum, and it's on one of my boxen. Will play tomorrow.

    Okay if I prod you for some tips when I hit walls?

    0
  • morbiuswilters

    @Cassidy said:

    Okay if I prod you for some tips when I hit walls?

    Sure thing.

    0
  • wrack

    Well, the point of systems like chef is ease of re-deployability of focused-on-some-task servers, as far as I understand.

    For those with a few machines of the hobby/small company "random pile of services" kind, re-deploying doesn't make much sense.



    However, stuff like etckeeper is useful in these cases.

    It's not in any sense replacement for the big management systems, but it's also worth knowing of, I think.




    <font size=1>     Probably incorrectly?</font>

    0
  • ?

    @dhromed said:

    @Nexzus said:
    What are the chances of a fix/improvement done by some random dude being put into production (for lack of a better term) on a large OSS project?
     

    Pretty much zero.

    The idea that opensourcing your software will cause it to be crowdsourced and increase its quality is a myth. You'll have a small group who are the developers, and everything will be the same as with closed source— except that there is transparency as to what the code does. That's all.

    Exactly right.  Any other "benefits" of open source are purely imaginary and do not acutally exist in the real world.

    I can submit a bug report, but I can't force them to actually do anything with it.

    I could write a patch to fix a bug or improve a feature, but that assumes  (a) I am well versed in whatever language the program is written in  (b) I am intimately familiar with the code base so that I know where to find the code that needs patching and (c) They will accept a patch from some random person.

    I could fork the code and create my own version of the program  But only if I'm an expert programmer in [whatever language] and only if I am willing to spend months trudging through tens of thousands of undocumented files. And for what?  Just so I can make a few minor improvements that have already been suggested by a hundred other people and ignored by arrogant developers?  No thanks.

     

    0
  • B

    @morbiuswilters said:

    The point is, he filed a bug report and it didn't get fixed. I think it's fair to use that as evidence supporting the case of "the FOSS model generally results in sub-standard quality software."

    So telling people they can fix FOSS bugs themselves is an option, sure, but I consider it an admission that most FOSS is a failure by any real metric. How many hours do I have to spend fixing bugs before it becomes more economical to just buy a working product? For a $500 piece of software that's, like, 3 hours. And that's my own personal time. If we're talking about company time, that figure is something like $1000 /hr. It is much more economical for my employer for me to spend $1000 on a working piece of software that has actual support rather than starting down the path of using a "free" alternative that I know will chew up at least 1 hour just trying to get the damn thing to work.

    And then if I uncover a bug and I'm told if I want to see it fixed I should do a git clone and get to steppin'? Yeah, sorry, that's an enormous waste of my employer's resources. The opportunity cost for lost revenue becomes extraordinary. If FOSS cannot compete under such conditions, then it has failed.

     

    Thats the fallacy that support of commerical products is actually helpful. In my experience it isn't better at all than support in "largish" FOSS projects, in general worse and you have 0 chance to fix it yourself.

    The products I'm admin on, you can basically forget support. Completely useless. They are so dumb it's would probably mostly be faster to fix the bug yourself than to explain them what is wrong with their shitty product. 

     

     

     

    0
  • morbiuswilters

    @beginner_ said:

    Thats the fallacy that support of commerical products is actually helpful.

    There is bad commercial support but no good FOSS support.

    @beginner_ said:

    ...in general worse...

    I don't believe you. I can see support as bad as a FOSS project, but not worse. It's simply not possible. If the CEO of the company comes to your house and shits on your doorstep, hosing it off is still less annoying than listening to Richard Stallman for five minutes.

    @beginner_ said:

    ...you have 0 chance to fix it yourself.

    When is this ever a real option? In the real world--where somebody wasn't already developing against a FOSS project, doing compiles and digging through the source and where they could easily make their own patch and submit it--I've rarely seen a FOSS bug fixed. I've seen people "patch" FOSS web apps written in PHP or whatever a couple of times. The patch was always a laughable hack and due to the fucked-up way it was implemented, it made it impossible to upgrade to a new version without comparing thousands of lines of source to see if the fucking patch needed to be replicated. So to workaround some bug they ended up causing years and years of unfixable bugs because nobody could ever upgrade the garbage.

    0
  • boomzilla
    ♿ (Parody)

    @morbiuswilters said:

    @beginner_ said:
    ...you have 0 chance to fix it yourself.

    When is this ever a real option?

    I have, on occasion, done this. I've also been able to find a patch that someone else wrote and applied it.

    @morbiuswilters said:

    I've seen people "patch" FOSS web apps written in PHP or whatever a couple of times. The patch was always a laughable hack and due to the fucked-up way it was implemented, it made it impossible to upgrade to a new version without comparing thousands of lines of source to see if the fucking patch needed to be replicated. So to workaround some bug they ended up causing years and years of unfixable bugs because nobody could ever upgrade the garbage.

    I've known a lot of stupid people, too. It seems like a common problem.

    0
  • B

    @El_Heffe said:

    @dhromed said:

    @Nexzus said:
    What are the chances of a fix/improvement done by some random dude being put into production (for lack of a better term) on a large OSS project?
     

    Pretty much zero.

    The idea that opensourcing your software will cause it to be crowdsourced and increase its quality is a myth. You'll have a small group who are the developers, and everything will be the same as with closed source— except that there is transparency as to what the code does. That's all.

    Exactly right.  Any other "benefits" of open source are purely imaginary and do not acutally exist in the real world.

    I can submit a bug report, but I can't force them to actually do anything with it.

    I could write a patch to fix a bug or improve a feature, but that assumes  (a) I am well versed in whatever language the program is written in  (b) I am intimately familiar with the code base so that I know where to find the code that needs patching and (c) They will accept a patch from some random person.

    I could fork the code and create my own version of the program  But only if I'm an expert programmer in [whatever language] and only if I am willing to spend months trudging through tens of thousands of undocumented files. And for what?  Just so I can make a few minor improvements that have already been suggested by a hundred other people and ignored by arrogant developers?  No thanks.

     

    I'm inherently skeptical of this line of argument. In particular, when I see one programmer loudly complaining about how another programmer won't do something, I question the first programmer's level of effort, and also his skill level. The narrative you construct about not knowing the language, lacking background info, etc. rings hollow. The other programmer(s) you're criticizing are likely immersed in some other project (or subproject) and would face a (re-) learning curve, too. Really, your comment sticks in my craw because, as a developer, I know how easy it is for an unfair division of labor to arise, in which one person, or a few people, end up doing everything. I don't expect much help with this issue from the lusers, but I do expect help from programmers.

    0
  • blakeyrat

    Ok open source defenders. If your software development methodology is so superior, explain Open Office/Libre Office vs. Microsoft Office. Is Libre Office less buggy than MS Office? Is it more innovative? Is it sleeker, faster code? It's so superior, explain to me how. Because I don't see it.

    0
  • Ben L.

    @blakeyrat said:

    Ok open source defenders. If your software development methodology is so superior, explain Open Office/Libre Office vs. Microsoft Office. Is Libre Office less buggy than MS Office? Is it more innovative? Is it sleeker, faster code? It's so superior, explain to me how. Because I don't see it.

    Hi I'm blakeyrat and I think that a sample size of 1 is a good way to understand thousands of things.

    Here's s sample size of three: nginx, gcc, git.

    0
  • B

    @blakeyrat said:

    Ok open source defenders. If your software development methodology is so superior, explain Open Office/Libre Office vs. Microsoft Office. Is Libre Office less buggy than MS Office? Is it more innovative? Is it sleeker, faster code? It's so superior, explain to me how. Because I don't see it.

    I don't use Open Office, but I'd be very careful about touting MS Office as some sort of paragon of virtue. The last couple "upgrades" have been unwelcome bloatware, according to a lot of the people I work with. And personally, I find working with Excel to be maddening. I really think I would prefer something a tad less "innovative." This is not 1980. Microsoft is not going to revolutionize the way people work with some new spreadsheet or word processor feature.

    0
  • boomzilla
    ♿ (Parody)

    @blakeyrat said:

    Ok open source defenders. If your software development methodology is so superior, explain Open Office/Libre Office vs. Microsoft Office. Is Libre Office less buggy than MS Office? Is it more innovative? Is it sleeker, faster code? It's so superior, explain to me how. Because I don't see it.

    TDEMSYR

    0
  • blakeyrat

    @Ben L. said:

    Here's s sample size of three: nginx, gcc, git.

    Never used, can't get excited about anything as fucking boring as a compiler, unusable fucking mess.

    "HEY GUYS open source makes a good compiler! ... that's ... exciting? I guess? Of course despite how good it is, everybody's abandoning it in droves for LLVM so."

    0
  • Ben L.

    @blakeyrat said:

    @Ben L. said:
    Here's s sample size of three: nginx, gcc, git.

    Never used, can't get excited about anything as fucking boring as a compiler, unusable fucking mess.

    "HEY GUYS open source makes a good compiler! ... that's ... exciting? I guess? Of course despite how good it is, everybody's abandoning it in droves for LLVM so."

    TDEMSYR
    0
  • B

    You know, MS Office seems pretty solid right now, but there was a period of several years during which it had a really annoying and nagging issue. Basically, the Office installer (little dialog with a meaningless progress bar) would open up randomly. More precisely, I think this related to using COM automation. It was amazing how much trouble Microsoft had with that. I remember thinking that their programmers were a bunch of incompetent asses... probably unfair, but let's not present Office as an example of anything good. It's just absurd.



    EDIT: Microsoft KB article 303439 seems to be a pathetic attempt to deal with this issue.

    0
  • Lorne Kates
    Trolleybus Mechanic

    LIAR!

     

    0
  • error
    Considered Harmful

    @El_Heffe said:

    I can submit a bug report, but I can't force them to actually do anything with it.

    This is my most recent experience with reporting a bug to closed-paid software (slightly anonymized):

    1. I open a detailed ticket in their tracker with full repro instructions for version 7.1.2 - the latest version available
    2. They acknowledge the bug an hour later and assign it to a developer.
    3. A few days later, the developer marks it resolved, fixed in version 8.0.

    Sounds good, right? Except version 8.0 isn't scheduled for release until late this year, and will cost an additional hundred dollars or so to upgrade to.

    0
  • morbiuswilters

    @Ben L. said:

    Here's s sample size of three: nginx, gcc, git.

    You're cherry-picking the best open source apps. Also, 99% of people don't give a shit about any of those. You'd barely be able to explain what they do to an average user. That doesn't make them useless, it just shows that the best FOSS software tends to be that which is used by other computer nerds.

    0
  • B

    @morbiuswilters said:

    the best FOSS software tends to be that which is used by other computer nerds.

    ...which is preferable to consumer-oriented garbageware, by any reasonable standard. It's not a point of pride to say that your best software is intended for people who have no damned business in front of a computer anyway.

    0
  • morbiuswilters

    @bridget99 said:

    @morbiuswilters said:
    the best FOSS software tends to be that which is used by other computer nerds.

    ...which is preferable to consumer-oriented garbageware, by any reasonable standard. It's not a point of pride to say that your best software is intended for people who have no damned business in front of a computer anyway.

    I think this sums up the FOSS attitude very well. Thank you, you did precisely what I hoped.

    0
  • dhromed

    That was amazing.

    I need a smoke.

    0
  • B

    @morbiuswilters said:

    @bridget99 said:
    @morbiuswilters said:
    the best FOSS software tends to be that which is used by other computer nerds.

    ...which is preferable to consumer-oriented garbageware, by any reasonable standard. It's not a point of pride to say that your best software is intended for people who have no damned business in front of a computer anyway.

    I think this sums up the FOSS attitude very well. Thank you, you did precisely what I hoped.

    Look, I understand mere mortals are going to use computers, and there's no returning to 1980. However, I think it's valid to criticize software as "too consumer-oriented." When I use that term, what I have in mind is shit like Clippy, interminable/instantaneous mandatory security patches, "My" everything on the desktop, troubleshooting / connectivity wizards that never work, and the like. When you make a piece of software that's designed for people who don't understand or even like computers, you're almost destined to make garbageware. Software that provides a thin, rational abstraction around the capabilities of the hardware will always be objectively better than software that tries to hide or distort these capabilities. When you say that (paraphrasing) "Microsoft makes granny software better," my natural response is "who cares?" Ralston-Purina makes better dog food than Emeril Lagasse... nobody's buying their cookbooks though.

    0
  • Ben L.

    @bridget99 said:

    Software that provides a thin, rational abstraction around the capabilities of the hardware will always be objectively better[...]

    Just to recap:

    • Computers do math
    • Calc.exe does math
    • bridget99's web browser of choice is Calc.exe
    0
  • ?

    @bridget99 said:

    I'm inherently skeptical of this line of argument. In particular, when I see one programmer loudly complaining about how another programmer won't do something, I question the first programmer's level of effort, and also his skill level.
    But that's exactly the point I was making, and the point that you clearly don't understand.  Everyone is not an expert programmer in every language.  Everyone is not intimately familair with the code base of every program.  As a result, open source software is not the "millions-of-people-looking-at-the-source-and-everyone-is-jumping-in-to-fix-it-and-make-it-better" utopia that some people try to claim.  And that's the issue I'm talking about here.  Because you don't even understand the issue, every one of your criticisms has absolutely nothing to do with what I wrote. @bridget99 said:
    The other programmer(s) you're criticizing are likely immersed in some other project (or subproject) and would face a (re-) learning curve, too.
    No.  I'm not complaing about some ramdom programmer somewhere.  I'm talking about the programmers who are working (and in many cases getting paid to work) on a specific piece of software right now. 

    I'm talking abot the programmer who closed the bug I submitted for Chrome as "no longer valid" even though the bug still exists in the latest version.  I'm talking about the programmers who ignore user requests/complaints because they're just "lusers" and who are they to tell us not to make stupid changes to our program.  

    And even though [insert program name here] is open source, there's nothing I can do about those problems because (a)  I'm not an expert programmer in [whatever language] - and neither is 99% of the rest of the world  (b) The code base of [whatever program] contains tens of thousands of flies and it would take me months to figure it out, and (c) Wy would I waste my time doing that? @bridget99 said:

    I don't expect much help with this issue from the lusers, but I do expect help from programmers.
    I not talking about what you do at work.  I'm talking about open source software in general.

    Pick any open source program.

    If you aren't an expert programmer in [whatever language] that program is written in

    And, you aren't intimately familiar with the code base

    And you really have better things to do with your life than spend months learning everything you need to know about that program just so you can attempt to make some minor imporvements that have already been suggested by a hundred other people but have been ignored by programmers who suffer from "not invented here" syndrome,

    Congratulations, you are a "luser" too.

     

    0
Log in to reply