> "if the application is not performing its' stated task, to provide audio playback, then it is a bad design."
> ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?
> wow, way to paint yourself into a corner, skippy.
Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things.
It is very clear that petrus4 was *not* saying the words you are trying to put in his mouth. It is clear that he is referring to the fact that since PulseAudio is having such widespread trouble performing its core functionality (playing sound) across so many systems, it is badly designed. And I completely agree with this position, personally. A well-designed system would not have so many problems.
Oh, and as for "bug reports" mentioned above, they're not a cure-all, nor an appropriate thing to suggest as a response when buggy and incomplete software is shoehorned into distributions. I'm also not going to waste my time putting together bug reports for PulseAudio specifically when the general attitude is as I stated in my original post- ie. everything-but-PulseAudio is to blame. Don't try to push the responsibility for a chain of poor decisions onto the people affected by them. I'll submit bug reports to the projects that I think will do something useful with them.
And to close- I will clarify that one reason I find the PulseAudio design so poor is that it simultaneously assumed and relied on all applications and drivers being perfect, such that it could be treated as a drop-in replacement. Which clearly didn't work- and really never had a chance to do so. I can't think of one half-competent person who would design a system with a vast culture of interacting applications with this assumption. By my words, I'm *not* saying or implying that the PulseAudio designers are incompetent, I am just baffled that they approached the design and integration of their system without taking this properly into account. I'm wondering what influences led to this decision. I'm guessing somebody with the know-how was pressured in some way for a deliverable. Anyway, PulseAudio integration leads to a gigantic regression in audio functionality in distributions. A properly-designed system would not cause this. Smash-it-all-and-let-people-pick-up-the-pieces isn't a solid design methodology. Oh, and let me be very clear. I am more than qualified to comment on this aspect of the design. So let's leave off any "not expert enough" arguments, okay?
Anyway, I'm done. What does such an argument achieve anyway? I'll save my positive contributions for the day when I see the PulseAudio developers and distribution integrators say: "Um, sorry guys, we sorta screwed up. What's the best way forward?"
You can choose to remain wilfully ignorant in order to make your point, or you can actually take into account the rest of the post you are replying to. I highlighted the general attitude around PulseAudio. Re-read the paragraph starting with "The order of the day...". I have seen examples of each of these things. Have you? If not, you can even find most of them in the article! Are you so tied up in PulseAudio advocacy that you really can't see these things happening?
Anyway, discussion has mostly moved on from here. My position on this whole thing is very clear. I'll drop a reply or two to another couple of posts you've made in this thread that caught my eye, and then I think I'll leave it at that.
>... but you have absolutely no right to go commenting on the fundamental architecture and design of PA itself for all the reasons QuoteMstr listed.
I choose not to remain silent on issues that are being repeatedly denied and deflected, despite being widespread. Why on earth should I? Oh- and I have plenty of experience working on systems that have had to interact with hideously-bad systems before, and compensate for their deficiencies. I could go into them, but why? You wouldn't consider it "good enough" if I did, because they weren't *specifically* related to audio.
> In open source you have to...
>... they keep on walking to the M$ or Appl store.
One: Stop being so arrogant as to assume you can lay down the rules as to what someone must do, while trying to champion your cause by flying the "open source" banner. Two: Stop trying to associate a broken audio subsystem with "open source" and "Linux versus Microsoft/Apple" in order to bolster the argument and gather numbers. You want to chat about these topics some time? Fine. But let's not pretend that PulseAudio problems are about either of these.
You're trying to attack my credibility rather than my content, implying I have said or done things that I have not, suggesting I have no right to comment in the first place, and to top it all off fall back to emotional arguments by trying to associate things with established Slashdot darlings. Do you honestly not expect to be called on so many logical fallacies, on Slashdot of all places?
Are you sure you're not just the same guy, just posting anonymously this time?
> My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified. You couldn't tell whether OpenAL or set BLASTER is the better API, and you're just throwing around big words in lashing out at being bitten by a bug. What you should be doing instead of foaming at the mouth here is filing real, helpful bug reports, helping track down problems, and generally trying to do something. Lambasting the PA developers for not "getting the core functionality right" when you couldn't even tell me what the hell the core functionality is is definitely not in the helpful range. How much did you pay for this crap again?
This will be my last reply to you.
You do not have to be an expert on a particular area in order to point out glaring problems that an enormous number of people are having, much like you do not have to be a chef to point out that your dinner is terrible.
You have absolutely no idea of my experience in this area, and you are making some very poor assumptions.
And pulling out the whole "it's free, so take what you're given" thing is ludicrous, and coincidentally the precise point at which I stopped taking you seriously.
> Perhaps you could call attention to particular aspects of PulseAudio's design you disagree with? Perhaps propose a better implementation? All I see above is an elaborate (if unhelpful) bug report.
I have no interest in digging into audio API design at this point, and certainly have no intention to be led into it in a lengthy attempted defence of my experiences prompted by your quick three-sentence reply.
But in at least a partial answer to your question, I did mention the importance of getting the core functionality correct. If you actually interested in my thoughts on what could be improved, and not just trying to discredit my post, then my suggestion would be to focus on that. Getting the core functionality right.
I've had three systems with audio problems. Two Ubuntu-based (8.04, 9.04), a third OpenSuSE-based. All with PulseAudio. All had oddities- ranging from the sound working only during X session startup/shutdown (and not in-between), through to the audio skipping, repeatedly, when changing the current desktop. These were on reasonably decent machines, by the way. Machines that should gobble up and spit this data so fast that it barely dents CPU usage.
In each case, disabling PulseAudio and using, well, anything else, caused the problem to go away. OSS, ALSA, didn't matter, they both worked. Sometimes it was easy to remove PulseAudio, and sometimes it took a bit of work. Ubuntu 9.04 was a challenge. No, scratch that, it was a fight.
I look around, I see horror stories and widespread problems with PulseAudio.
I see claims that it works, if you configure it "properly". You know, I heard the same vague defence regarding Windows' instability. I didn't believe it for Windows either.
I've heard that PulseAudio has a great set of features. However, I have no interest in digging into what these features might be. The core feature that I want above all else isn't supported by PulseAudio. That feature?
Playing seamless audio.
PulseAudio can't even get that right. Stutters and skips are the norm, audio systems that worked previously no longer do, and the backers of this abomination are in abject denial about it. There are widespread complaints about it across multiple applications and multiple operating systems, and still it "isn't configured properly". You can't be serious. Complaints about PulseAudio are not really shared by the majority of technical people? Oh, yes they are.
If you want to provide a reasonable sound system, a *core* focus has to be on providing a working sound system. Get the core functionality right, then move onto features. Stability, correctness. Get the basics right. Also understand that API users may stuff things up, and falling over and dying is not the correct thing to do. The infrastructure needs to be resilient, not fragile.
PulseAudio did *not* do this. Any of this.
The order of the day seems to be to blame everything *but* PulseAudio. The apps are broken, the drivers are broken, the operating system maintainers didn't integrate it properly, it's not configured properly for the user's machine, the people complaining wouldn't be complaining if they were more technical, a lot of distros have adopted it so it must be good. Did I miss anything here? This has been the argument thus far.
I'm going to be different. I'm not going to blame the developers, the applications, the users, the knowledge of the users, the operating system developers, or anyone else. I'm going to blame the one at fault, the *cause* of these problems. The one thing in common with this incredible list of problems.
PulseAudio is completely and utterly broken- in design, in implementation, and in application. It is horrendous, shameful, and embarrassing.
Hasn't every chipset maker- ever- been busted for fudging benchmark results at some point? Multiple times, usually?
And then they get caught out by the old exe-renaming technique.
Why do they keep trying it? The mind boggles.
I would have thought by now that a standard tool in the benchmarkers repertoire was a tool that copied each benchmark exe to a different name and location and launched that, followed by a launch with the default name; and that the more popular benchmarks had options to tweak the test ordering and methodology slightly to make application profiling difficult.
Thankyou for an informative post. Even if the current moderation score doesn't reflect it, I promise you that there are people out there who appreciate it.
I don't think that the anti-dollar-sign thing is really Slashdot groupthink. More an organised effort by motivated individuals over the years to change public perception of their brand. Some years back on Slashdot I watched as a number of astroturfing slashdot IDs suddenly changed their focus to criticise anyone who applied the dollar to any variant of Microsoft's name. It was generally the same accounts, over and over, all posting in support of each other. They were literally searching the comments for the text "M$" or "Micro$oft", and making condescending and belittling posts in response, every time. Personally, I don't think that it's Slashdot consensus (or groupthink) as such, more that certain motivated individuals are happy to keep propagating the idea that it might be. Sometimes this will be expressed in a coordinated attempt to suppress a comment through moderation.
I wouldn't be ashamed or reluctant to post "Micro$oft", especially if you feel that they deserve to be mocked in this way. Sure, you'll draw criticism and downmods from those protecting the brand and the simple-minded who have been manipulated into going along with them. But at the end of the day, Slashdot karma is cheap, and it's better to get your opinion out there than fearing what the possible reaction to it might be.
Set up a single dedicated machine with four large (500GB) drives. Script it to replicate the data across the drives. In case of errors or differences, it should default to the most reliable copy (compare the copies across drives). Make it notify on drive failure or file loss.
Once a year, boot it up, run the script. Leave it for the day or two it takes to run. Remove any bad drives, and replace them. Once the process is complete, shut it down again. Repeat next year. Upgrade the hardware from time to time, and replace any drives that get "too" old, even if they haven't failed.
If you want to do it on the cheap, always use the last-gen drives and hardware on it. Better than throwing it out.
Easy. Tell them you'll be expecting them to work with Ruby on Rails, AJAX, Extreme Programming, Web 2.0, Web 3.0, heck, why not Web 4.0 too (just keep adding numbers as you need). Wait for the blood to drain from their faces. Then suggest whatever you like, they'll do anything else you say at this point.
More seriously, find out the problems they like to solve. If you have any good ones, you won't be able to shut them up after you ask this. You might need to give them time to think it over, though. If none respond, you don't have a strong team, and I have no advice to offer. If you have one or more, see if you can figure out where to place them in whatever grand design you are managing, based on their preferences. Get their input- and they will have input- about the problem you are trying to solve. Break off problems to solve from the main design for the good ones, and break off specific tasks for the weaker ones. If people run with their tasks and go above and beyond, shift more of the problem solving onto them, and reduce the amount of management. If you have any very good ones, they'll eventually manage themselves, you'll just have to give them a stream of problems to solve. If they are not as capable, pay more attention, turn more problems into specific tasks. Get the input of the stronger ones. For the ones that demonstrate their ability to take a problem and solve it, act quickly on their input. Once they see that better work leads to more independence and greater input, they'll have a reason to strive.
There's a fair few more things to cover, especially the knowledge gap from being in a business stream *and* younger, but this'll have to do for now.
Must-learns, even if you don't stick with them: C and Java. Yes, Java can be extremely unpleasant to deal with at times, but it is worth knowing. C is very useful to know, but honestly, I'd learn it last.
If whitespace-is-syntax bugs you (it bugs me) and you want a good scripting language, then try Ruby. It's not as mature as Python, but I can highly recommend it.
Perl is ubiquitous, but it's really a write-only language.;) *ducks multiple flamethrowers*
Knowing shell scripting (ie. sh) is of course nice, but for anything non-trivial, you should be learning one of: Perl, Python, or Ruby.
If the president-elect was using a Zune stolen violently from a small child, that would justify "Zunegate".
If the president-elect secretly pumped millions of dollars of public funds into Zune development, that would justify "Zunegate".
If the president-elect was found in an inappropriate coupling with an intern and they were both listening to Zunes at the time, that would justify "Zunegate".
He's just using one. Are there really people who are genuinely disturbed, concerned, or bothered in the slightest that he's listening to music on a Zune? No don't answer that. Perhaps I should ask: Should anyone in their right mind be even slightly concerned?
So what if he's using one!? He probably has other music players at home if it really bothers people.
And don't even get me started on "instead of an iPod". Geeesh.
Because my music player is smaller, lighter, more feature-laden, has more storage, has a brighter and larger screen, plays videos, fits in my shirt pocket without weighing it down, has a non-fragile USB plug, accepts standard headphones, has incredible battery life, and works far better under Linux than my phone.
Microsoft promise a lot of things. Let's see if this feature is still there once Windows 7 is out and about.
Anyway, if you're serious about 3D, you're going to get a dedicated 3D card, or at least a decent integrated one. That doesn't mean what they are doing is a bad idea. It is actually a *splendid* idea. Good on them. The reason I say this is that if a particular feature is lacking on the card you have, you can always fall back to software to use it anyway. Sure, performance won't be great, but you can still use it. This is particularly important if using such a feature is the *only* option- it lets you use software you otherwise could not. It also makes development much easier- you can target a particular feature, knowing that everyone will have it, via the software renderer in the worst case. I certainly hope it is available for hardware renderers to selectively fall back on if they lack a certain feature, but I suspect it'll just be a full software solution.
(it's a bit late here, please forgive any mistakes in the above)
Lawyer up. Seriously, book an hour or two with a lawyer, discuss things, and ask about the legal ramifications. If you're seriously going to make a software product, eliminate the risks up front with a few hundred dollars rather than spending months or years and tens of thousands of dollars and *then* finding out you will be obliterated if you release it.
Remember, the legal system is not about who is in the moral right, nor does it automatically side with the more talented party. A judge is not going to say "I herby order that those losers at your old company had this coming to them". If legal action is brought against you, you could quite easily be financially destroyed if you *win*, let alone what might happen if you lose.
Now, not being a lawyer I can't offer any legal advice on your particular situation. From a technical perspective I'd seriously consider differentiating your product in some way so that it solves a particular problem your old code didn't, and doesn't solve one problem that your old code did. Grow that product, and if in time you still want to kick the legs out from under your old company, then add the missing functionality and turn your product into something that competes directly. Then crush them mercilessly. Chances are though that by this point you'll just be more interested in making your own product great.
Determine approximate non-IT payroll. Use market values if you must. Estimate the time it would take for non-skilled IT folk to fix their problems, deal with virus outbreaks, etc, across all areas. Multiply by wage. This is figure A.
Call around and get some IT consulting rates. Multiply by hours you work. Factor in travel time of consultants, multiplied by wages lost by local employees in this travel time. This is figure B.
Your wage is figure C.
Provide to PHB, including breakdown. If you've done it right, A > B > C. Put a big red circle around the figure for C.
There are not that many weirdo's experimenting with weird games these days.
There are plenty. However, the set of people who succeed in making the game, find the concept actually works, polish it enough to hold a new player's interest, explain it well enough to hook people, make it run on as many systems as possible, run a website, and actively market it to get people to notice it, is much smaller.
I honestly don't understand this at all. If boot time is important, why not make two simple changes:
User "Shut Down": Reboot, get to login screen, suspend to disk. User "Power On": Return from suspend.
They are technically simple as well. When the user does a "Shut Down", drop a file in the filssystem somewhere. Reboot. On reaching login, if the file exists, immediately suspend.
The only downside would be a slower shutdown time- but honestly, who cares?
Firstly, don't pay too much attention to the naysayers who are knocking back the idea entirely or saying to just give them a console to take home. I'm guessing the reason is to give your devs something to do to unwind from time to time, and possibly get them playing together occasionally to bring the team together.
Unfortunately, you are setting yourself up for serious resentment by monitoring console use. Sure, it might seem fair from your point-of-view, you don't want people abusing it. Fair enough. But consider it from the devs point-of-view. They know there is a fun toy there. They know they can play it. They also know *if* they do, a note is being taken somewhere, and it could damage their career in the future at some point. Do they have exact guidelines as to what is allowed? Are they risking trouble if they are actively seen playing games for a few hours a week, even if they restrict it to certain hours? By including this monitoring, you are effectively tormenting your devs by giving them a toy they dare not use. They will end up resenting you for it.
I know that if I was in such a place, the instant I knew that usage was monitored, I'd set the console aside, under my desk, and use it as a footrest. There's no way I'm risking my career to play a game from time to time. If anyone asked, I'd just say I was caught up in my work and didn't really feel like playing then. I'll just wait 'til I get home and play games then. Seeing the console there would make me resent my employer.
If you must monitor, is there some way that you can set a "sensible" limit, and "monitor" use only insofar as making sure that each dev doesn't hit the limit? And if they do, let them know they'll get a warning first, not be reported to the higher-ups? And also let them know that usage information isn't being retained or used against them, it's just being checked to make sure it isn't excessive, then discarded?
I think a better solution would be to tell people to limit their time to x hours per week, or outside of certain hours, or similar, and then leave it at that. If it's getting abused, people who are following the rules are going to kick up. You've got bigger problems to deal with if you can't trust your employees to track their own time.
Another possibility is to set regular "team-building" times, where you all get together and play games together to unwind. If your office also need to be on-call, you might need a standby roster where one person (known well in advance) covers for everyone else in case a client comes by.
As for video capture, can you just track how long the console has been powered on instead? Why do you need screencaps of the console? The only possibility I can see is if they used it as a media player (ie. listen to music whilst working).
As for discretion, could the console just go in a tray with a lid, so that when it isn't in use, it is just a blank box on the desk? If anyone asks, it is to keep dust off the unit. The real reason is so that you're not giving the impression that all your area does is play games.
And last of all- why a console per developer? Why not just set up a rec area, with a comfy chair, console, and good headphones (or give each person their own headphones). Then track the time they spend in the rec room, instead.
Alternatively, have a game console box, where each of the major consoles is present. Set all the cables up for each employee at their work area, with controllers inside their desk drawers. When they want to play, they go to the console box, check out their console and game(s) of choice, and take it back to play. You can then track the console checkouts instead.
I don't have too much to offer for debs either, I have had far less exposure to them. My knowledge on them was based mostly on other people's technical takes on it at the time, and from the sounds of it, neither deb nor RPM were really a clear leader. My original assertion probably came off as anti-RPM (and that is true, to a degree, due to my negative experiences with it), but my main focus was really on saying that there was no clear leader at the time, and each tool had advantages over the other, so standardising on one was a bad idea. Not everyone will agree, of course- just my personal opinion. Standards groups are such odd things.;)
Combining what you've said, and I've said, we have RPM as using a poor, not well-supported interface, the official tools (rpmbuild) perhaps not being the best for the job, and the people behind the format historically not doing the best job to use or support it- we probably disagree on the relevance of the last point though. There's also the build-as-root issue I mentioned too.
Might just be me, but that really doesn't seem much of an endorsement for RPM.;)
If you've worked with RPM since Redhat 6 then there's a good chance we've had some similar experiences, and to a degree would come to similar conclusions. In fact, with this vintage you would have experienced the RPM 3->4 fiasco first-hand. This would have been circa 2002 or so, I think? I didn't mark it on my calendar.;)
As originally mentioned, I just concentrated on my own personal gripes with it. If at this point we still disagree on the specifics of the relative merit of the format and tools, we probably aren't going to reach a quick consensus through swapping of personal anecdotes and dissection thereof. So I'll just leave it at that for now. At the least you're aware of the opinions of one person, and if the perception of RPM is important to you, you've now got some potential areas to attack to ensure its general approval, should you choose to do so.
Why does it matter which particular tar-like-format+header they use?
At the time when LSB was being heavily promoted initially (years and years ago) there was no clear leader (in terms of technical merit) in the packaging format arena, and worse, each of the leaders was somewhat flawed. Different distros used different formats for vastly different reasons. This was not an area in which they should have nailed things down to a single format as it would alienate too many distros. They did, and it did.
I could go on and on about the reasons why standardising on RPM was a terrible idea, but I'll just leave it at the three reasons I personally grew to hate RPM (on a Redhat system):
- No easy way to get the contents of an rpm out. The cpio tools at the time kept crashing randomly. I'd never even heard of cpio at the time. Why use that format? - An assumption that you'll be running build scripts as root. What sort of thought process led to that? - The RPM 4 upgrade RPM from Redhat, packaged in RPM 4 format. Think about that one for a while.
Of course, *using* RPMs is a different story. They do the job (mostly).
If you haven't had a play with rpmbuild, I suggest doing so. It's probably moved on since I last used it though, so perhaps they've cleaned up their act.
What I don't know is how these men sleep at night. How do they live with themselves?
They sleep and live very well. To such people, such actions are no different than choosing to step forward first with the left foot rather than the right.
I used to spend hours trying to rationalise it, fit it into my worldview, figure out how they stop the guilt and shame gnawing away at them. There is no internal struggle. There is no guilt and shame. That is how they do it.
Slashdot Mirror
> HAHa you owned him hard.
For sufficiently low values of "owned", I'm guessing.
> "if the application is not performing its' stated task, to provide audio playback, then it is a bad design."
> ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?
> wow, way to paint yourself into a corner, skippy.
Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things.
It is very clear that petrus4 was *not* saying the words you are trying to put in his mouth. It is clear that he is referring to the fact that since PulseAudio is having such widespread trouble performing its core functionality (playing sound) across so many systems, it is badly designed. And I completely agree with this position, personally. A well-designed system would not have so many problems.
Oh, and as for "bug reports" mentioned above, they're not a cure-all, nor an appropriate thing to suggest as a response when buggy and incomplete software is shoehorned into distributions. I'm also not going to waste my time putting together bug reports for PulseAudio specifically when the general attitude is as I stated in my original post- ie. everything-but-PulseAudio is to blame. Don't try to push the responsibility for a chain of poor decisions onto the people affected by them. I'll submit bug reports to the projects that I think will do something useful with them.
And to close- I will clarify that one reason I find the PulseAudio design so poor is that it simultaneously assumed and relied on all applications and drivers being perfect, such that it could be treated as a drop-in replacement. Which clearly didn't work- and really never had a chance to do so. I can't think of one half-competent person who would design a system with a vast culture of interacting applications with this assumption. By my words, I'm *not* saying or implying that the PulseAudio designers are incompetent, I am just baffled that they approached the design and integration of their system without taking this properly into account. I'm wondering what influences led to this decision. I'm guessing somebody with the know-how was pressured in some way for a deliverable. Anyway, PulseAudio integration leads to a gigantic regression in audio functionality in distributions. A properly-designed system would not cause this. Smash-it-all-and-let-people-pick-up-the-pieces isn't a solid design methodology. Oh, and let me be very clear. I am more than qualified to comment on this aspect of the design. So let's leave off any "not expert enough" arguments, okay?
Anyway, I'm done. What does such an argument achieve anyway? I'll save my positive contributions for the day when I see the PulseAudio developers and distribution integrators say: "Um, sorry guys, we sorta screwed up. What's the best way forward?"
> Where 'abject denial' is defined as documenting the issues and workarounds - https://fedoraproject.org/wiki/Bug_info_PulseAudio#Playback_problems.2C_crackling_or_skipping - and fixing them (most of the issues of this kind were fixed by kernel fixes in the last six months)? Wow, it's like a whole new vocabulary world out here.
You can choose to remain wilfully ignorant in order to make your point, or you can actually take into account the rest of the post you are replying to. I highlighted the general attitude around PulseAudio. Re-read the paragraph starting with "The order of the day...". I have seen examples of each of these things. Have you? If not, you can even find most of them in the article! Are you so tied up in PulseAudio advocacy that you really can't see these things happening?
Anyway, discussion has mostly moved on from here. My position on this whole thing is very clear. I'll drop a reply or two to another couple of posts you've made in this thread that caught my eye, and then I think I'll leave it at that.
> ... but you have absolutely no right to go commenting on the fundamental architecture and design of PA itself for all the reasons QuoteMstr listed.
I choose not to remain silent on issues that are being repeatedly denied and deflected, despite being widespread. Why on earth should I? Oh- and I have plenty of experience working on systems that have had to interact with hideously-bad systems before, and compensate for their deficiencies. I could go into them, but why? You wouldn't consider it "good enough" if I did, because they weren't *specifically* related to audio.
> In open source you have to ...
> ... they keep on walking to the M$ or Appl store.
One: Stop being so arrogant as to assume you can lay down the rules as to what someone must do, while trying to champion your cause by flying the "open source" banner. Two: Stop trying to associate a broken audio subsystem with "open source" and "Linux versus Microsoft/Apple" in order to bolster the argument and gather numbers. You want to chat about these topics some time? Fine. But let's not pretend that PulseAudio problems are about either of these.
You're trying to attack my credibility rather than my content, implying I have said or done things that I have not, suggesting I have no right to comment in the first place, and to top it all off fall back to emotional arguments by trying to associate things with established Slashdot darlings. Do you honestly not expect to be called on so many logical fallacies, on Slashdot of all places?
Are you sure you're not just the same guy, just posting anonymously this time?
I think I'll post this one sans Karma bonus.
> My point is that you have no business commenting on PulseAudio's design. You're not qualified, and you're not even interested in becoming qualified. You couldn't tell whether OpenAL or set BLASTER is the better API, and you're just throwing around big words in lashing out at being bitten by a bug. What you should be doing instead of foaming at the mouth here is filing real, helpful bug reports, helping track down problems, and generally trying to do something. Lambasting the PA developers for not "getting the core functionality right" when you couldn't even tell me what the hell the core functionality is is definitely not in the helpful range. How much did you pay for this crap again?
This will be my last reply to you.
You do not have to be an expert on a particular area in order to point out glaring problems that an enormous number of people are having, much like you do not have to be a chef to point out that your dinner is terrible.
You have absolutely no idea of my experience in this area, and you are making some very poor assumptions.
And pulling out the whole "it's free, so take what you're given" thing is ludicrous, and coincidentally the precise point at which I stopped taking you seriously.
> Perhaps you could call attention to particular aspects of PulseAudio's design you disagree with? Perhaps propose a better implementation? All I see above is an elaborate (if unhelpful) bug report.
I have no interest in digging into audio API design at this point, and certainly have no intention to be led into it in a lengthy attempted defence of my experiences prompted by your quick three-sentence reply.
But in at least a partial answer to your question, I did mention the importance of getting the core functionality correct. If you actually interested in my thoughts on what could be improved, and not just trying to discredit my post, then my suggestion would be to focus on that. Getting the core functionality right.
I've had three systems with audio problems. Two Ubuntu-based (8.04, 9.04), a third OpenSuSE-based. All with PulseAudio. All had oddities- ranging from the sound working only during X session startup/shutdown (and not in-between), through to the audio skipping, repeatedly, when changing the current desktop. These were on reasonably decent machines, by the way. Machines that should gobble up and spit this data so fast that it barely dents CPU usage.
In each case, disabling PulseAudio and using, well, anything else, caused the problem to go away. OSS, ALSA, didn't matter, they both worked. Sometimes it was easy to remove PulseAudio, and sometimes it took a bit of work. Ubuntu 9.04 was a challenge. No, scratch that, it was a fight.
I look around, I see horror stories and widespread problems with PulseAudio.
I see claims that it works, if you configure it "properly". You know, I heard the same vague defence regarding Windows' instability. I didn't believe it for Windows either.
I've heard that PulseAudio has a great set of features. However, I have no interest in digging into what these features might be. The core feature that I want above all else isn't supported by PulseAudio. That feature?
Playing seamless audio.
PulseAudio can't even get that right. Stutters and skips are the norm, audio systems that worked previously no longer do, and the backers of this abomination are in abject denial about it. There are widespread complaints about it across multiple applications and multiple operating systems, and still it "isn't configured properly". You can't be serious. Complaints about PulseAudio are not really shared by the majority of technical people? Oh, yes they are.
If you want to provide a reasonable sound system, a *core* focus has to be on providing a working sound system. Get the core functionality right, then move onto features. Stability, correctness. Get the basics right. Also understand that API users may stuff things up, and falling over and dying is not the correct thing to do. The infrastructure needs to be resilient, not fragile.
PulseAudio did *not* do this. Any of this.
The order of the day seems to be to blame everything *but* PulseAudio. The apps are broken, the drivers are broken, the operating system maintainers didn't integrate it properly, it's not configured properly for the user's machine, the people complaining wouldn't be complaining if they were more technical, a lot of distros have adopted it so it must be good. Did I miss anything here? This has been the argument thus far.
I'm going to be different. I'm not going to blame the developers, the applications, the users, the knowledge of the users, the operating system developers, or anyone else. I'm going to blame the one at fault, the *cause* of these problems. The one thing in common with this incredible list of problems.
PulseAudio is completely and utterly broken- in design, in implementation, and in application. It is horrendous, shameful, and embarrassing.
Hasn't every chipset maker- ever- been busted for fudging benchmark results at some point? Multiple times, usually?
And then they get caught out by the old exe-renaming technique.
Why do they keep trying it? The mind boggles.
I would have thought by now that a standard tool in the benchmarkers repertoire was a tool that copied each benchmark exe to a different name and location and launched that, followed by a launch with the default name; and that the more popular benchmarks had options to tweak the test ordering and methodology slightly to make application profiling difficult.
Thankyou for an informative post. Even if the current moderation score doesn't reflect it, I promise you that there are people out there who appreciate it.
I don't think that the anti-dollar-sign thing is really Slashdot groupthink. More an organised effort by motivated individuals over the years to change public perception of their brand. Some years back on Slashdot I watched as a number of astroturfing slashdot IDs suddenly changed their focus to criticise anyone who applied the dollar to any variant of Microsoft's name. It was generally the same accounts, over and over, all posting in support of each other. They were literally searching the comments for the text "M$" or "Micro$oft", and making condescending and belittling posts in response, every time. Personally, I don't think that it's Slashdot consensus (or groupthink) as such, more that certain motivated individuals are happy to keep propagating the idea that it might be. Sometimes this will be expressed in a coordinated attempt to suppress a comment through moderation.
I wouldn't be ashamed or reluctant to post "Micro$oft", especially if you feel that they deserve to be mocked in this way. Sure, you'll draw criticism and downmods from those protecting the brand and the simple-minded who have been manipulated into going along with them. But at the end of the day, Slashdot karma is cheap, and it's better to get your opinion out there than fearing what the possible reaction to it might be.
Set up a single dedicated machine with four large (500GB) drives. Script it to replicate the data across the drives. In case of errors or differences, it should default to the most reliable copy (compare the copies across drives). Make it notify on drive failure or file loss.
Once a year, boot it up, run the script. Leave it for the day or two it takes to run. Remove any bad drives, and replace them. Once the process is complete, shut it down again. Repeat next year. Upgrade the hardware from time to time, and replace any drives that get "too" old, even if they haven't failed.
If you want to do it on the cheap, always use the last-gen drives and hardware on it. Better than throwing it out.
Easy. Tell them you'll be expecting them to work with Ruby on Rails, AJAX, Extreme Programming, Web 2.0, Web 3.0, heck, why not Web 4.0 too (just keep adding numbers as you need). Wait for the blood to drain from their faces. Then suggest whatever you like, they'll do anything else you say at this point.
More seriously, find out the problems they like to solve. If you have any good ones, you won't be able to shut them up after you ask this. You might need to give them time to think it over, though. If none respond, you don't have a strong team, and I have no advice to offer. If you have one or more, see if you can figure out where to place them in whatever grand design you are managing, based on their preferences. Get their input- and they will have input- about the problem you are trying to solve. Break off problems to solve from the main design for the good ones, and break off specific tasks for the weaker ones. If people run with their tasks and go above and beyond, shift more of the problem solving onto them, and reduce the amount of management. If you have any very good ones, they'll eventually manage themselves, you'll just have to give them a stream of problems to solve. If they are not as capable, pay more attention, turn more problems into specific tasks. Get the input of the stronger ones. For the ones that demonstrate their ability to take a problem and solve it, act quickly on their input. Once they see that better work leads to more independence and greater input, they'll have a reason to strive.
There's a fair few more things to cover, especially the knowledge gap from being in a business stream *and* younger, but this'll have to do for now.
Must-learns, even if you don't stick with them: C and Java. Yes, Java can be extremely unpleasant to deal with at times, but it is worth knowing. C is very useful to know, but honestly, I'd learn it last.
If whitespace-is-syntax bugs you (it bugs me) and you want a good scripting language, then try Ruby. It's not as mature as Python, but I can highly recommend it.
Perl is ubiquitous, but it's really a write-only language. ;) *ducks multiple flamethrowers*
Knowing shell scripting (ie. sh) is of course nice, but for anything non-trivial, you should be learning one of: Perl, Python, or Ruby.
If the president-elect was using a Zune stolen violently from a small child, that would justify "Zunegate".
If the president-elect secretly pumped millions of dollars of public funds into Zune development, that would justify "Zunegate".
If the president-elect was found in an inappropriate coupling with an intern and they were both listening to Zunes at the time, that would justify "Zunegate".
He's just using one. Are there really people who are genuinely disturbed, concerned, or bothered in the slightest that he's listening to music on a Zune? No don't answer that. Perhaps I should ask: Should anyone in their right mind be even slightly concerned?
So what if he's using one!? He probably has other music players at home if it really bothers people.
And don't even get me started on "instead of an iPod". Geeesh.
Because my music player is smaller, lighter, more feature-laden, has more storage, has a brighter and larger screen, plays videos, fits in my shirt pocket without weighing it down, has a non-fragile USB plug, accepts standard headphones, has incredible battery life, and works far better under Linux than my phone.
But apart from that, no reason at all.
Microsoft promise a lot of things. Let's see if this feature is still there once Windows 7 is out and about.
Anyway, if you're serious about 3D, you're going to get a dedicated 3D card, or at least a decent integrated one. That doesn't mean what they are doing is a bad idea. It is actually a *splendid* idea. Good on them. The reason I say this is that if a particular feature is lacking on the card you have, you can always fall back to software to use it anyway. Sure, performance won't be great, but you can still use it. This is particularly important if using such a feature is the *only* option- it lets you use software you otherwise could not. It also makes development much easier- you can target a particular feature, knowing that everyone will have it, via the software renderer in the worst case. I certainly hope it is available for hardware renderers to selectively fall back on if they lack a certain feature, but I suspect it'll just be a full software solution.
(it's a bit late here, please forgive any mistakes in the above)
Lawyer up. Seriously, book an hour or two with a lawyer, discuss things, and ask about the legal ramifications. If you're seriously going to make a software product, eliminate the risks up front with a few hundred dollars rather than spending months or years and tens of thousands of dollars and *then* finding out you will be obliterated if you release it.
Remember, the legal system is not about who is in the moral right, nor does it automatically side with the more talented party. A judge is not going to say "I herby order that those losers at your old company had this coming to them". If legal action is brought against you, you could quite easily be financially destroyed if you *win*, let alone what might happen if you lose.
Now, not being a lawyer I can't offer any legal advice on your particular situation. From a technical perspective I'd seriously consider differentiating your product in some way so that it solves a particular problem your old code didn't, and doesn't solve one problem that your old code did. Grow that product, and if in time you still want to kick the legs out from under your old company, then add the missing functionality and turn your product into something that competes directly. Then crush them mercilessly. Chances are though that by this point you'll just be more interested in making your own product great.
Determine approximate non-IT payroll. Use market values if you must. Estimate the time it would take for non-skilled IT folk to fix their problems, deal with virus outbreaks, etc, across all areas. Multiply by wage. This is figure A.
Call around and get some IT consulting rates. Multiply by hours you work. Factor in travel time of consultants, multiplied by wages lost by local employees in this travel time. This is figure B.
Your wage is figure C.
Provide to PHB, including breakdown. If you've done it right, A > B > C. Put a big red circle around the figure for C.
Then get on with your real work.
There are not that many weirdo's experimenting with weird games these days.
There are plenty. However, the set of people who succeed in making the game, find the concept actually works, polish it enough to hold a new player's interest, explain it well enough to hook people, make it run on as many systems as possible, run a website, and actively market it to get people to notice it, is much smaller.
I honestly don't understand this at all. If boot time is important, why not make two simple changes:
User "Shut Down": Reboot, get to login screen, suspend to disk.
User "Power On": Return from suspend.
They are technically simple as well. When the user does a "Shut Down", drop a file in the filssystem somewhere. Reboot. On reaching login, if the file exists, immediately suspend.
The only downside would be a slower shutdown time- but honestly, who cares?
Firstly, don't pay too much attention to the naysayers who are knocking back the idea entirely or saying to just give them a console to take home. I'm guessing the reason is to give your devs something to do to unwind from time to time, and possibly get them playing together occasionally to bring the team together.
Unfortunately, you are setting yourself up for serious resentment by monitoring console use. Sure, it might seem fair from your point-of-view, you don't want people abusing it. Fair enough. But consider it from the devs point-of-view. They know there is a fun toy there. They know they can play it. They also know *if* they do, a note is being taken somewhere, and it could damage their career in the future at some point. Do they have exact guidelines as to what is allowed? Are they risking trouble if they are actively seen playing games for a few hours a week, even if they restrict it to certain hours? By including this monitoring, you are effectively tormenting your devs by giving them a toy they dare not use. They will end up resenting you for it.
I know that if I was in such a place, the instant I knew that usage was monitored, I'd set the console aside, under my desk, and use it as a footrest. There's no way I'm risking my career to play a game from time to time. If anyone asked, I'd just say I was caught up in my work and didn't really feel like playing then. I'll just wait 'til I get home and play games then. Seeing the console there would make me resent my employer.
If you must monitor, is there some way that you can set a "sensible" limit, and "monitor" use only insofar as making sure that each dev doesn't hit the limit? And if they do, let them know they'll get a warning first, not be reported to the higher-ups? And also let them know that usage information isn't being retained or used against them, it's just being checked to make sure it isn't excessive, then discarded?
I think a better solution would be to tell people to limit their time to x hours per week, or outside of certain hours, or similar, and then leave it at that. If it's getting abused, people who are following the rules are going to kick up. You've got bigger problems to deal with if you can't trust your employees to track their own time.
Another possibility is to set regular "team-building" times, where you all get together and play games together to unwind. If your office also need to be on-call, you might need a standby roster where one person (known well in advance) covers for everyone else in case a client comes by.
As for video capture, can you just track how long the console has been powered on instead? Why do you need screencaps of the console? The only possibility I can see is if they used it as a media player (ie. listen to music whilst working).
As for discretion, could the console just go in a tray with a lid, so that when it isn't in use, it is just a blank box on the desk? If anyone asks, it is to keep dust off the unit. The real reason is so that you're not giving the impression that all your area does is play games.
And last of all- why a console per developer? Why not just set up a rec area, with a comfy chair, console, and good headphones (or give each person their own headphones). Then track the time they spend in the rec room, instead.
Alternatively, have a game console box, where each of the major consoles is present. Set all the cables up for each employee at their work area, with controllers inside their desk drawers. When they want to play, they go to the console box, check out their console and game(s) of choice, and take it back to play. You can then track the console checkouts instead.
I don't have too much to offer for debs either, I have had far less exposure to them. My knowledge on them was based mostly on other people's technical takes on it at the time, and from the sounds of it, neither deb nor RPM were really a clear leader. My original assertion probably came off as anti-RPM (and that is true, to a degree, due to my negative experiences with it), but my main focus was really on saying that there was no clear leader at the time, and each tool had advantages over the other, so standardising on one was a bad idea. Not everyone will agree, of course- just my personal opinion. Standards groups are such odd things. ;)
Combining what you've said, and I've said, we have RPM as using a poor, not well-supported interface, the official tools (rpmbuild) perhaps not being the best for the job, and the people behind the format historically not doing the best job to use or support it- we probably disagree on the relevance of the last point though. There's also the build-as-root issue I mentioned too.
Might just be me, but that really doesn't seem much of an endorsement for RPM. ;)
If you've worked with RPM since Redhat 6 then there's a good chance we've had some similar experiences, and to a degree would come to similar conclusions. In fact, with this vintage you would have experienced the RPM 3->4 fiasco first-hand. This would have been circa 2002 or so, I think? I didn't mark it on my calendar. ;)
As originally mentioned, I just concentrated on my own personal gripes with it. If at this point we still disagree on the specifics of the relative merit of the format and tools, we probably aren't going to reach a quick consensus through swapping of personal anecdotes and dissection thereof. So I'll just leave it at that for now. At the least you're aware of the opinions of one person, and if the perception of RPM is important to you, you've now got some potential areas to attack to ensure its general approval, should you choose to do so.
Good luck!
Why does it matter which particular tar-like-format+header they use?
At the time when LSB was being heavily promoted initially (years and years ago) there was no clear leader (in terms of technical merit) in the packaging format arena, and worse, each of the leaders was somewhat flawed. Different distros used different formats for vastly different reasons. This was not an area in which they should have nailed things down to a single format as it would alienate too many distros. They did, and it did.
I could go on and on about the reasons why standardising on RPM was a terrible idea, but I'll just leave it at the three reasons I personally grew to hate RPM (on a Redhat system):
- No easy way to get the contents of an rpm out. The cpio tools at the time kept crashing randomly. I'd never even heard of cpio at the time. Why use that format?
- An assumption that you'll be running build scripts as root. What sort of thought process led to that?
- The RPM 4 upgrade RPM from Redhat, packaged in RPM 4 format. Think about that one for a while.
Of course, *using* RPMs is a different story. They do the job (mostly).
If you haven't had a play with rpmbuild, I suggest doing so. It's probably moved on since I last used it though, so perhaps they've cleaned up their act.
Are they still insisting on RPM, and acting surprised when the adoption rate is so low?
What I don't know is how these men sleep at night. How do they live with themselves?
They sleep and live very well. To such people, such actions are no different than choosing to step forward first with the left foot rather than the right.
I used to spend hours trying to rationalise it, fit it into my worldview, figure out how they stop the guilt and shame gnawing away at them. There is no internal struggle. There is no guilt and shame. That is how they do it.