No, I don't -- our phones were all owned by the folks we were subletting from in our last building. Even so, it's not exactly bad advice you're providing -- I'm fairly happy with the SPA-2000s we have already (for connecting our analog fax machines).
The SPA-841s are great if you don't need good speakerphone support -- their remote administration support is especially great, if you can just get the docs (which Sipura for some reason only makes available to resellers, partners and such). Only unresolved issue I'm having with them is sometimes incoming calls on secondary lines time out and so go straight to voicemail instead of ringing -- still haven't figured out that one yet. My vendor advised IP-600's when I asked them about phones w/ better speakerphone capability... will be interested to look into it and see if there's any relevant differences between those and the earlier models.
First: I'm not saying it's hard. I'm saying it's too hard for my manager, who hasn't taken a 2-week course. (I taught myself in less than two weeks -- but for my manager, who is extremely busy with his job of managing stuff, even two days is an unthinkably long amount of time to devote to learning a technical skill).
Second: I'm not speaking of PBX systems in general; I'm speaking of Asterisk in particular. Your 1960s ideas-and-technology PBX isn't going to have any sort of ability to decide to route a call based on who's logged in to Jabber or be configured to update a database given user selections or so forth.
Treating a post as an opportunity to go into a general-purpose, tangentially-related rant rather than respond to the actual points made is a breach of etiquette I've been guilty of in the past -- but that makes it no less a breach.
Of course there is, if you buy it from a vendor -- and there are plenty of them out there. Even with a 3rd party providing pretested hardware, service/support, etc, the price is vastly lower than the proprietary competition. Need uptime? There are plenty of failover technologies out there, and no good excuse (other than the cost of having extra hardware and connectivity) for not using them.
Sure, using Asterisk means you have the option of going the cheap way out -- it doesn't mean you have to, though.
Dial plans look like regular expressions, and even the folks with the pretty GUIs don't change that, because you'd basically need to invent another visual programming language to GUIfy them, and those suck.
Programming moderately-advanced user-driven functionality like letting users dial an extension to [arbitrary example] change call forwarding numbers, or [other arbitrary example] rerecord voice prompts -- is actually programming. The steps for validating that the user is who they ought to be, or coming from where they're supposed to; prompting them; storing data in the right places; coping nicely with error conditions -- it's all real programming, inasmuch as doing it right necessarily involves writing code. Sure, you can have a prepackaged solution that lets users do the most common tasks trivially from a GUI -- but any business that wants even moderately interesting things done will need something nontrivial done, and at that point you need to have the ability for someone who knows how to code get in and get things done.
Just the basics of "configuring the phones" -- that can be done from a GUI already. Hell, the prepackaged Asterisk-based solution we bought (before customizing the hell out of it) has a web UI for adding phone extensions, and the phones are all web-administrable as well (through a very, very slick interface). That doesn't mean that the coders are out of the loop, though, for anything but the most trivial of changes. The suits want to change the behaviour of calls to the main line so that they act differently based on business hours or whether the secretary is logged in to the company Jabber server? Needs skilled labor. The suits want to automatically charge customers phone calls made to the support line based on caller ID, and allow the support folks to override it at will? Needs skilled labor.
The thing is, though, I'm not just saying "needs skilled labor" as in "this is how it is right now"; I'm saying it as in "every attempt for the last 30 years to enable suits to do this kind of thing [creating application logic] unassisted has failed", starting with COBOL.
So, in conclusion: To the extent that there is such a need to allow managers to configure the thing, and to the extent that that need can actually be fulfilled, it already exists.
WRT tapping lines and rerouting calls -- having just installed an Asterisk-based phone system at work, I find myself not informing the business-types of its full capabilities just for the sake of not making them nervous. Very, very cool stuff -- though we now have some extra dependencies involved in making the phones work, we also have a fully customizable (and largely customized), featureful phone system. As it is, we're tied into a T1 for the outside world and doing VoIP (IAX when we can and SIP when we can't) to talk to the phones themselves. Features on the TODO list include integration with the CRM system (to make a note whenever a customer calls one of us or visa-versa, for instance) -- nothing about it's hard, just time-consuming.
Unfortunately, IP phones with quality full-duplex speakerphone support (unlike the otherwise excellent Sipura SPA-841s we're using) are *expensive*. (Know of a sub-$200 SIP phone with good speakerphone support? Let me know!)
If I recognize the brand, that means the company could afford advertising, which means the products are over priced.
Or it could mean that the company is attempting to sell to a large enough audiance to take advantage of economies of scale, thus being able to give you a cheaper product (even with the advertising cost) than if they'd turned out only a small number of units w/o an advertising budget.
One of my upstreams has unlimited usage with a spelled-out surcharge which may be levied, at the ISP's option, on users above the 98th percentile (or therebouts). It may not be well-defined what constitutes "top 2 percentile" for a given month ahead of time -- but it's a policy that's clearly spelled out in their contract up-front, and nobody who's reasonably consciencious wrt their bandwidth usage should be suprised if it's levied against them. I think this is more reasonable than providing the customer with no info whatsoever on the limits of their "unlimited" usage.
The complaint isn't that you're not allowed to saturate your upstream bandwidth on an inexpensive broadband account. The complaint is that they aren't upfront about it, and only tell you after you've broken their invisible limit (whatever it may be).
I think that having clearly spelled out contractual terms is worthwhile.
Agreed -- though snapshotting *is* necessary to get consistant state, that's provided by AFS (when backing up our fileservers), Oracle (when backing up database contents) and LVM (everywhere else).
In addition, "intellectual property tax" legislation is under consideration that may make the copyright expire sooner if it isn't registered with taxing authorities.
Wouldn't such legislation violate treaties (I think the Berne Convention) the US is subject to?
You cannot prevent one of those 5 customers from giving the software to someone else.
No, but why would they? They paid a bunch of money in order to get a competitive advantage from it, right? They might sell another copy to someone (and they could get away with that) -- but what's their motivation to give it away?
Further, even if a customer did resell it, the original developer could offer better support and services, since... well, they're the original developer.
I don't see anything wrong with what the (great? grand?) parent poster's company is doing -- not even in theory.
Kernel modules compiled for RHEL3 work on WBEL3 -- I've used WBEL at the office for test servers we didn't want to buy licenses for. (Presently, it's a moot point -- we're switching to SLES).
As far as I'm concerned, unless Red Hat makes some major changes to their business practices, SuSE's got #1 worldwide tied up -- just a matter of time.
See, Novell actually understands the whole bit about caring for your customers -- giving them engineering time during their R&D phase, being willing to negotiate on pricing, including engineers bearing schwag on sales calls, the whole bit. Red Hat treated us as just another faceless customer for a mass-market product. Novell has a local engineer who knows my name I can call for help whenever I need it.
Even ignoring their engineering advantages -- when it comes to knowing what it takes to sell to business, Novell has what it takes while Red Hat still has their heads up their rears.
If you're using kickstart properly, you can fully customize the set of installed RPMs -- you want to customize stuff? Replace some of the stock RPMs with your own builds, add your own, etc. and do it all during the kickstart. This whole installing-and-fixing-things-manually thing is bullshit, and doesn't scale.
(I'm senior deployment engineer at a software company that's gearing up to ship a SLES9-based sealed-box solution in reasonably large numbers).
Selling a Linux distro certified to work with Oracle is something one actually can make money off of. There are only two, and the other one's more expensive and (IMNSHO) technically inferior.
What really matters from the point of view of these companies, though, is what distros people buy "enterprise" variants of, pay for the customisation and deployment of, and pay for support on.
Just so. As a current customer of RHEL in the process of switching to SLES9 (with a great deal of engineering assistance from Novell -- for free!), though, I can say that SuSE's enterprise variant is pretty damn compelling. Their 2.6-based kernel gets substantially better performance on the hardware we're shipping to customers, they have more useful and better-written tools and packages (and they make a much more substantial attempt to be LSB-compliant in terms of stuff like init script design), their licensing on dual-processor x86_64 systems is much cheaper -- and most importantly of all, they actually give a damn about us as a customer.
We haven't sent them money yet -- it's all just R&D so far -- but that's changing in the very near future.
Did you spend a lot of money on a DB cert, only to be angered that others are getting the same job done with OSS and good programming techniques?
Maybe he spent a lot of time cleaning up a legacy (read: developers bailed long ago) database application that was consistantly hitting bugs that wouldn't have existed if the DB had been safeguarding the app layer from screwing up too bad. That kind of experience tends to lead to a fairly nontrivial amount of anger over bad databases (and, worse, refusal of app developers to use readily available good ones).
I *have* seen actual DB corruption -- but more often, I've just seen bad inserts that a competant database, used correctly, could have stopped the app layer from committing. It's bad enough when you're the initial developer -- it's a whole different ballpark when you're the guy who's been hired on to clean up his mess.
It's a Good Thing that MySQL has finally caught on and started trying to do things right. I wonder, though, how long it'll take for the developers weaned on it to do likewise.
As for biases, it is a reporter's job to suppress those biases and opinions and write an objective story.
But you've acknowledged that, in practice, that doesn't happen! Biases do have influence, even if it's a reduced amount when trying to suppress them. Making an honest attempt to show the other side of a story on which one takes a position is fine -- indeed, necessary. Pretending that said opposing side is adequately represented by that attempt, however, more often than not does them an injustice.
Anyone looking to the news media for "objective truth" is looking in the wrong place, no matter how many different sources they digest.
Maybe so -- but for anything beyond what can be directly observed, one needs to get information from somewhere.
If I lived in Austin, I wouldn't want to be able to discern what the Chronicle thought about the mayor and the city council by reading the front page.
Why not? You certainly wouldn't want to use it as your sole source of information -- but using it in combination with an alternate news source (with a different perspective, perhaps even with a directly opposed bias) works well. Moreover, the Chronicle speaks fairly effectively for a good number of people; by reading it, I can have a good idea of what my coworker Lou is going to be talking about when politics come up.
If a reporter's biases lead him to deliberately craft an inaccurate story, that seems to me to be personal dishonesty. If the same biases implicitly impact a story, without any intent on the reporter's part, I don't think that's dishonest, either intellectually or personally.
I agree with you that the former case is personally dishonest. As for the latter case, however, my position is that intellectual honesty requires one to acknowledge one's biases. That doesn't necessarily mean prefacing a story with a statement thereof -- but it also means not pretending to be completely impartial if one has a personal position on a topic.
In any event -- this isn't fun anymore, and I have Real Work to do; consequently, I'm out. Your position is reasonable, and likely even correct (which is to say that I don't wholeheartedly believe the arguments made prior to this paragraph). Even so, I'm still inclined to think of/. as something very much like a blog, and so acknowledge that they're not even trying to hold themselves to professional standards (so why get upset when they fail?). Been an enjoyable discussion; thanks for having it.
You made the claim that all journalists are dishonest
No, I didn't. I said that journalists who attempt to disguise their biases are dishonest. That's different from "all" journalists. I also left out a key word that would have better represented my thoughts but made this debate a bit less fun -- I consider the behaviour in question intellectual dishonesty, as opposed to the unqualified variety.
You made the claim that all journalists are dishonest and failed to provide any evidence.
Evidence is only needed if we disagree on the facts. We both agree that journalists commonly attempt to behave in an unbiased manner; and I think you accept my premise that there are other manners (selection of sources, etc etc) in which bias nonetheless asserts itself.
Could it be that your own biases lead you to label any journalist who writes stories that don't support your own preconceived notions as dishonest?
Probably not. The form of intellectual dishonesty I've been discussing here isn't one I think of much in the real world, and being guilty of it doesn't lead me to internally consider someone dishonest in general; it's just something that happens as a result of following best practices [of trying to behave in an unbiased manner to the point where the only remaining biases are disguised]. Other than the fellow who was lobbing Bush easy questions, I can't offhand think of a single journalist I consider personally, as opposed to intellectually, dishonest. (Biased? Absolutely! Dishonest, no).
Incidentally, I consume quite a lot of paper media, ranging from the Austin Chronicle (which is, generally, quite unabashed about its biases) to the WSJ (which is less straightforward about its, though they're reasonably visible). I don't consider the WSJ worse media than the Chronicle -- much the opposite is true -- though in this one respect, the Chronicle is more straightforward with its readership.
Clear, now?
I still find it curious that you consider/. such bad media but consume it nonetheless. Do you expect your complaints to change anything? If not, what's the point?
It's been fun trying to play defense, but I'm getting tired of it. So, wrapping that up...
It was, very likely, a deliberate use of a specific, sensationalistic, and inaccurate, word to play to the biases of the Slashdot crowd.
Very well -- let's say that I accept your accusation to be correct. So what? It's a goddamn blog. Have you ever seen Taco or company claim to be an professional journalist following accepted practices in the profession? I haven't, and I've been here quite some time.
I think it puts then down in the gutter with tabloids and talk radio and makes a sucker out of you.
I'd be a sucker if I believed what they said without thinking first. As it is, though, their biases are crystal clear -- making it trivial to determine where they differ from my own beliefs.
So why are you, oh discerning one, reading material out of the gutter? Does that make you a sucker as well?
If the IG report didn't explicitly use the word "lie" to describe the TSA's action, then Slashdot's use of that word in a headline attached to a story about the IG report was inaccurate and lacking in integrity.
I take it real journalists aren't allowed to paraphrase either?
regardless of your wordsmithing and sophistry.
If you can't find a better counterargument, I think I've won that point.
Contrary to your twisted notion that journalists are dishonest only when they suprress their own opinions and biases and write accurate stories supported by facts
No, journalists are dishonest (not "only" dishonest) when they write stories supported by a set of facts which they chose based on their prior knowledge, selection of contacts, etc. but attempt to deny the biases inherent in those factors. It's entirely possible for two different people to write two different, fact-supported stories with completely different viewpoints while still each honestly believing that they are accurately representing objective truth. Those who imply otherwise are deceiving their readership and, frequently, themselves.
Slashdot Mirror
Do you have a good speakerphone already for pots?
No, I don't -- our phones were all owned by the folks we were subletting from in our last building. Even so, it's not exactly bad advice you're providing -- I'm fairly happy with the SPA-2000s we have already (for connecting our analog fax machines).
The SPA-841s are great if you don't need good speakerphone support -- their remote administration support is especially great, if you can just get the docs (which Sipura for some reason only makes available to resellers, partners and such). Only unresolved issue I'm having with them is sometimes incoming calls on secondary lines time out and so go straight to voicemail instead of ringing -- still haven't figured out that one yet. My vendor advised IP-600's when I asked them about phones w/ better speakerphone capability... will be interested to look into it and see if there's any relevant differences between those and the earlier models.
I tried finding some consultant or company who could do this for us, but no luck.
Did you try the Bristol Group? (I don't work there or have ownership interest -- just a reasonably satisfied customer).
First: I'm not saying it's hard. I'm saying it's too hard for my manager, who hasn't taken a 2-week course. (I taught myself in less than two weeks -- but for my manager, who is extremely busy with his job of managing stuff, even two days is an unthinkably long amount of time to devote to learning a technical skill).
Second: I'm not speaking of PBX systems in general; I'm speaking of Asterisk in particular. Your 1960s ideas-and-technology PBX isn't going to have any sort of ability to decide to route a call based on who's logged in to Jabber or be configured to update a database given user selections or so forth.
Treating a post as an opportunity to go into a general-purpose, tangentially-related rant rather than respond to the actual points made is a breach of etiquette I've been guilty of in the past -- but that makes it no less a breach.
There's no vendor backup
Of course there is, if you buy it from a vendor -- and there are plenty of them out there. Even with a 3rd party providing pretested hardware, service/support, etc, the price is vastly lower than the proprietary competition. Need uptime? There are plenty of failover technologies out there, and no good excuse (other than the cost of having extra hardware and connectivity) for not using them.
Sure, using Asterisk means you have the option of going the cheap way out -- it doesn't mean you have to, though.
Dial plans look like regular expressions, and even the folks with the pretty GUIs don't change that, because you'd basically need to invent another visual programming language to GUIfy them, and those suck.
Programming moderately-advanced user-driven functionality like letting users dial an extension to [arbitrary example] change call forwarding numbers, or [other arbitrary example] rerecord voice prompts -- is actually programming. The steps for validating that the user is who they ought to be, or coming from where they're supposed to; prompting them; storing data in the right places; coping nicely with error conditions -- it's all real programming, inasmuch as doing it right necessarily involves writing code. Sure, you can have a prepackaged solution that lets users do the most common tasks trivially from a GUI -- but any business that wants even moderately interesting things done will need something nontrivial done, and at that point you need to have the ability for someone who knows how to code get in and get things done.
Just the basics of "configuring the phones" -- that can be done from a GUI already. Hell, the prepackaged Asterisk-based solution we bought (before customizing the hell out of it) has a web UI for adding phone extensions, and the phones are all web-administrable as well (through a very, very slick interface). That doesn't mean that the coders are out of the loop, though, for anything but the most trivial of changes. The suits want to change the behaviour of calls to the main line so that they act differently based on business hours or whether the secretary is logged in to the company Jabber server? Needs skilled labor. The suits want to automatically charge customers phone calls made to the support line based on caller ID, and allow the support folks to override it at will? Needs skilled labor.
The thing is, though, I'm not just saying "needs skilled labor" as in "this is how it is right now"; I'm saying it as in "every attempt for the last 30 years to enable suits to do this kind of thing [creating application logic] unassisted has failed", starting with COBOL.
So, in conclusion: To the extent that there is such a need to allow managers to configure the thing, and to the extent that that need can actually be fulfilled, it already exists.
WRT tapping lines and rerouting calls -- having just installed an Asterisk-based phone system at work, I find myself not informing the business-types of its full capabilities just for the sake of not making them nervous. Very, very cool stuff -- though we now have some extra dependencies involved in making the phones work, we also have a fully customizable (and largely customized), featureful phone system. As it is, we're tied into a T1 for the outside world and doing VoIP (IAX when we can and SIP when we can't) to talk to the phones themselves. Features on the TODO list include integration with the CRM system (to make a note whenever a customer calls one of us or visa-versa, for instance) -- nothing about it's hard, just time-consuming.
Unfortunately, IP phones with quality full-duplex speakerphone support (unlike the otherwise excellent Sipura SPA-841s we're using) are *expensive*. (Know of a sub-$200 SIP phone with good speakerphone support? Let me know!)
If I recognize the brand, that means the company could afford advertising, which means the products are over priced.
Or it could mean that the company is attempting to sell to a large enough audiance to take advantage of economies of scale, thus being able to give you a cheaper product (even with the advertising cost) than if they'd turned out only a small number of units w/o an advertising budget.
One of my upstreams has unlimited usage with a spelled-out surcharge which may be levied, at the ISP's option, on users above the 98th percentile (or therebouts). It may not be well-defined what constitutes "top 2 percentile" for a given month ahead of time -- but it's a policy that's clearly spelled out in their contract up-front, and nobody who's reasonably consciencious wrt their bandwidth usage should be suprised if it's levied against them. I think this is more reasonable than providing the customer with no info whatsoever on the limits of their "unlimited" usage.
Why not complain about something worthwhile?
The complaint isn't that you're not allowed to saturate your upstream bandwidth on an inexpensive broadband account. The complaint is that they aren't upfront about it, and only tell you after you've broken their invisible limit (whatever it may be).
I think that having clearly spelled out contractual terms is worthwhile.
There was no such threshold when I was a customer with TimeWarner, and I have no such limit with my current Charter account.
You mean you never heard about it because you never hit it. If you were using the full bandwidth available to you 24/7, OTOH, you would have.
Agreed -- though snapshotting *is* necessary to get consistant state, that's provided by AFS (when backing up our fileservers), Oracle (when backing up database contents) and LVM (everywhere else).
In addition, "intellectual property tax" legislation is under consideration that may make the copyright expire sooner if it isn't registered with taxing authorities.
Wouldn't such legislation violate treaties (I think the Berne Convention) the US is subject to?
In the article text, he admitted that there would still be work done by humans -- hanging doors, installing windows and such.
Not sure whether you'd be able to get 300 hours out of it, though.
You cannot prevent one of those 5 customers from giving the software to someone else.
No, but why would they? They paid a bunch of money in order to get a competitive advantage from it, right? They might sell another copy to someone (and they could get away with that) -- but what's their motivation to give it away?
Further, even if a customer did resell it, the original developer could offer better support and services, since... well, they're the original developer.
I don't see anything wrong with what the (great? grand?) parent poster's company is doing -- not even in theory.
Kernel modules compiled for RHEL3 work on WBEL3 -- I've used WBEL at the office for test servers we didn't want to buy licenses for. (Presently, it's a moot point -- we're switching to SLES).
As far as I'm concerned, unless Red Hat makes some major changes to their business practices, SuSE's got #1 worldwide tied up -- just a matter of time.
See, Novell actually understands the whole bit about caring for your customers -- giving them engineering time during their R&D phase, being willing to negotiate on pricing, including engineers bearing schwag on sales calls, the whole bit. Red Hat treated us as just another faceless customer for a mass-market product. Novell has a local engineer who knows my name I can call for help whenever I need it.
Even ignoring their engineering advantages -- when it comes to knowing what it takes to sell to business, Novell has what it takes while Red Hat still has their heads up their rears.
If you're using kickstart properly, you can fully customize the set of installed RPMs -- you want to customize stuff? Replace some of the stock RPMs with your own builds, add your own, etc. and do it all during the kickstart. This whole installing-and-fixing-things-manually thing is bullshit, and doesn't scale.
(I'm senior deployment engineer at a software company that's gearing up to ship a SLES9-based sealed-box solution in reasonably large numbers).
Selling a Linux distro certified to work with Oracle is something one actually can make money off of. There are only two, and the other one's more expensive and (IMNSHO) technically inferior.
We haven't sent them money yet -- it's all just R&D so far -- but that's changing in the very near future.
Did you spend a lot of money on a DB cert, only to be angered that others are getting the same job done with OSS and good programming techniques?
Maybe he spent a lot of time cleaning up a legacy (read: developers bailed long ago) database application that was consistantly hitting bugs that wouldn't have existed if the DB had been safeguarding the app layer from screwing up too bad. That kind of experience tends to lead to a fairly nontrivial amount of anger over bad databases (and, worse, refusal of app developers to use readily available good ones).
I *have* seen actual DB corruption -- but more often, I've just seen bad inserts that a competant database, used correctly, could have stopped the app layer from committing. It's bad enough when you're the initial developer -- it's a whole different ballpark when you're the guy who's been hired on to clean up his mess.
It's a Good Thing that MySQL has finally caught on and started trying to do things right. I wonder, though, how long it'll take for the developers weaned on it to do likewise.
In any event -- this isn't fun anymore, and I have Real Work to do; consequently, I'm out. Your position is reasonable, and likely even correct (which is to say that I don't wholeheartedly believe the arguments made prior to this paragraph). Even so, I'm still inclined to think of /. as something very much like a blog, and so acknowledge that they're not even trying to hold themselves to professional standards (so why get upset when they fail?). Been an enjoyable discussion; thanks for having it.
You made the claim that all journalists are dishonest
/. such bad media but consume it nonetheless. Do you expect your complaints to change anything? If not, what's the point?
No, I didn't. I said that journalists who attempt to disguise their biases are dishonest. That's different from "all" journalists. I also left out a key word that would have better represented my thoughts but made this debate a bit less fun -- I consider the behaviour in question intellectual dishonesty, as opposed to the unqualified variety.
You made the claim that all journalists are dishonest and failed to provide any evidence.
Evidence is only needed if we disagree on the facts. We both agree that journalists commonly attempt to behave in an unbiased manner; and I think you accept my premise that there are other manners (selection of sources, etc etc) in which bias nonetheless asserts itself.
Could it be that your own biases lead you to label any journalist who writes stories that don't support your own preconceived notions as dishonest?
Probably not. The form of intellectual dishonesty I've been discussing here isn't one I think of much in the real world, and being guilty of it doesn't lead me to internally consider someone dishonest in general; it's just something that happens as a result of following best practices [of trying to behave in an unbiased manner to the point where the only remaining biases are disguised]. Other than the fellow who was lobbing Bush easy questions, I can't offhand think of a single journalist I consider personally, as opposed to intellectually, dishonest. (Biased? Absolutely! Dishonest, no).
Incidentally, I consume quite a lot of paper media, ranging from the Austin Chronicle (which is, generally, quite unabashed about its biases) to the WSJ (which is less straightforward about its, though they're reasonably visible). I don't consider the WSJ worse media than the Chronicle -- much the opposite is true -- though in this one respect, the Chronicle is more straightforward with its readership.
Clear, now?
I still find it curious that you consider