the real question is -- are they going to support XMPP S2S (server to server federation)? Currently it looks like port xmpp.oscar.aol.com:5269 is NOT accepting connections (that's the XMPP S2S port).
Without S2S, this announcement is pretty much useless -- I mean, sure I can use my jabber client against AOL instead of the AOL-branded one, but I pretty much can do that already via the reverse-engineered joscar libraries (e.g. libgaim)
> Heck he might have actually believed that Linux was ripping off SCO's IP.
No, really he didn't. Don't fall into that trap: having an open mind does NOT mean you never hold people accountable. Not everybody in the world is good, and in this case it is clear that Darl (and others) were trying to game the system for their own benefit.
That said, shooting Darl is clearly not right. But he definitely needs to pay a significant personal penalty for this.
Except that the developer builds (and betas!) for Vista have been widely available both inside and outside of Microsoft for quite some time. As an ex-employee of MS, I'll bet you that at least 90% of the developers at Microsoft are running Vista on one of their boxes right now. So the "not out yet" excuse really doesn't hold water here.
The first 20 minutes of the new user's experience is critical in a consumer application like this. Requiring Joe Customer to go and download an update so that their brand new Zune works with their brand new PC is inexcusable.
I think the vulnerability isn't much of an issue for the intended use: protecting secure areas against infiltration. Sure, the Bad Guys (tm) could take them out from a distance, but the act of doing so would alert you to their presence.
This would free up a lot of manpower, since you don't have to have a person watching every inch of real estate -- it would be really useful for lessening the number of people you need to stay awake on "watch" while your platoon beds down for the night, or lowering the amount of manned guard towers you need along the DMZ. You still need real people to back up the machines, but you probably can get away with a lot less of them.
Sure, you could argue that a CCTV system does just as good a job of freeing up manpower, but I think the gun is a slightly better deterrent. I know from personal experience that I really am not that scared of sneaking past a closed-circuit camera, but I sure as hell am not going to try and sneak past this thing.
The difference is the margin of error. Basic scuba diving certification teaches you how to free ascend with no air from the deepest dive you'll ever make without a backup air source (~100ft: beyond that and you start doing things like taking a backup "pony bottle" air source). In a true panic situation where you can't swim up with the air you have left, you quick-release your weight belt, start blowing out (yes, blow out!), and your natural boyancy will take you to the surface -- without weight you'll go up pretty fast. Dropping weights is only for true emergencies -- usually you can just swim up since the air in your lungs will expand as you go up, making it surprisingly easy to ascend even from relatively deep dives without additional air.
Soo, to answer your question:
forgetting to check your compressed air: lose weight belt, feel stupid
forgetting to check your jet pack: crash and die.
It is important to note that the ACLU has only file a FOIA request at this point: they haven't filed expensive lawsuits or spent a ton of money yet -- so don't jump to complain just yet.
Actually you're missing something: I have a Macbook Pro, I run OSX primarily -- but I'd like the OPTION of occasionally running windows on the box, mostly so I can run PC-only games.
I never understood why he was CEO at A9...he's definitely a scientist and *not* a CEO type. I assumed that the weird A9-is-a-company-but-really-part-of-Amazon thing allowed him to do it: but I can't imagine it was the best use of him.
Most likely because there would be something in the "licensing agreement" to protect the patent holder from exactly this kind of thing....some legal language that basically says "even if the patents are found invalid, we still get to keep your money"
If the patent holder could be shown to have been working in bad faith (ie they knew the patent should not be valid, but were extorting the money anyway) then it is probably a different situation, but that would be a very difficult thing to prove.
As someone who's used quite a few web-based and client-based bug trackers over the years, I'll say that Bugzilla's web interface leaves a *LOT* to be desired: you are seriously limited in the complexity of queries you can write, your sorting options are laughable, general result layout is very poor, etc etc.
So I was prety excited when I saw this post - I downloaded the product and immediately tried it out. Unfortunately this product doesn't really add much: sorting is unimproved, the query builder is a little (not much) better, the layout and UI is unattractive and not signifcantly more powerful than the Web UI -- plus the product is pretty slow overall and consumes a frightening amount of system resources (150M memory, 300M VM space, according to TaskMan)
Overall, if this were a free product, I might use it: however for $99/seat it just isn't worth it right now.
Except that for print advertising, the SENDER pays the bulk of the costs (in the form of postage) wheras with electronic spam, the RECEIVER pays the cost (in terms of mail storage space and processing) --- therefore junk-snail-mail tends to be somewhat self-regulating, wheras junk email is not.
"Eagle is already in talks with a large networking company that is interested in handing out phones to its employees to learn how its organization really works, compared with how the company's organizational chart says it works."
This actually seems like a useful idea -- this kind of thing (tracking off-org-chart interactions in large companies) is something that has been studied and written about for a long time, and the cell-phone system seems like a really good way to do it. Neat.
The firware and filesystems use a number of tricks to ensure "wear leveling" between blocks so that there aren't 'really frequently written blocks' for the most part -- the blocks are all written fairly equally.
In fact, this makes for interesting filesystems: filesystems which don't put control structures into well-known blocks, etc etc.
Umm, I could be missing something, but your initial statement that "Photoelectric won't work, won't solve even a small fraction of our power needs, not remotely" seems to be completely wrong.
...So, finishing the math: using 15% efficiency solar cells, the Average US Household needs only 40 square meters (430 square feet) of solar cells to cover all its energy needs. Heck, I could use 5% solar cells on my roof in downtown San Francisco, and STILL have 2x extra capacity to sell back to the grid!
Don't get me wrong: Solar won't solve everything, particularly in applications like transportation where energy storage is an issue --- and cheap Fission IS something we should have figured out a long time ago --- but please don't resort to misinformation to make your points, it only weakens what you are saying.
Fair enough -- but the thing is that they'd end up looking like your specific packets and therefore would be relatively easy to filter at the ISP level.
The advantage of SSL is that it is a standard proto which is opaque: an ISP can't filter SSLed VOIP packets b/c there is too much legit SSL traffic that they'd also be blocking. As soon as you start using UDP, it becomes easier for an ISP to block it.
Unfortunately UDP cannot be run over SSL -- and UDP is a better protocol for many of these P2P apps in many situations: better firewall traversal, better performance when packets are lost (for audio and other 'real time' protocols, TCP's guaranteed ordering is quite a problem as it causes already-received packets to be buffered waiting for a previous retransmission), etc etc.
XML has some things going for it -- as a markup language for primarily text data (eg web pages) it works fairly well.
At a high level, XML is *CONCEPTUALLY* a great idea. I like the DOM programming model -- it is very expressive, and yet even complicated data tends to be understandable when represented as a DOM tree. Unfortunately, the basic text-XML representation that everybody uses is a terrible wire format from an efficiency and ease-of-programming perspective.
The real problem with XML is the massive inefficiency at the lower levels. XML is easily 2x-5x less efficient than comparable wire formats. For example I once worked on a project for an Instant Messaging server which used XML to communicate. I abstracted out the very lowest-level protocol layers so that they used simple XML token-compression and attribute-name compression....the result was a fully 400% increase in throughput through the server! This is primarily because the processor has so much less data to process (less string comparasins, string copies, etc) and therefore the memory bandwidth requirements are significantly lower.
Complexity of parsing is an issue as well. Writing a complete XML parser is full of subtleties and surprisingly difficult -- don't jump in and say otherwise unless you've actually done it. If you don't believe me, go look at how complicated something like the expat source or the dom4j source is.
A primary XML design goal (go read the XML designer's notes) was for ease-of-human-reading: this comes at the expense of efficient machine reading. Because data is not length-prefixed, and of arbitrary length, there are massive inefficiencies in buffering which leads to a lot of copying as you parse. There are never any "hints" in the protocol about what is coming up: and so parsers are forced to buffer things for an arbitrary amount of time (looking for that closing/> for example) and end up using a lot of memory and doing a lot of buffer expanding, or complex buffer-chaining stuff.
Additionally, a text-based representation like XML is extremely inefficient for binary data. Having to parse through all of your data and escape/unescape special characters is yet another big performance hit.
A standardized and fully-supported binary XML representation would have a huge impact on the performance of things we use every day -- and it could all happen at the low levels without even touching app-level code.
Running Cat5 between buildings can be quite a problem, depending on the distance and such: lightning strikes or even small ground potential differences between buildings can destroy ethernet equipment. Remember, copper ethernet equipment is designed for very low voltage and even a small current flow can cause serious damage. Wireless is almost certainly a better bet for what you want.
If they advertised the position as full-time, and then are trying to do a bait-and-switch for contracting: don't buy it. Is this the kind of place you want to work for? Do you really believe them when they say they'll move you to full-time? What credibility do they have at this point?
In all my years as a hiring manager, I've never had a situation where I advertised a position and then "couldn't get approval". You don't advertise the position before you get approval. There *are* situations where I meet a candidate and interview them for one position, realize they aren't a good fit but decide I still want to hire them into the organization -- in those situations I might offer them a contracting role with the hope of getting a full-time spot: but I am always very clear that this is a different position than the one they came in originally for.
If you do decide to take the job, remember that the tax rates are often higher and you'll need to cover things like benefits, etc. Contractor should be _substantially_ higher than a full-time salary (say 40-50% higher as a guess, but definitely research that # more). Saving for retirement will also cost you more: look into things like a SEP IRA or a traditional IRA.
When you're working as a contractor, make sure to keep track of your expenses, keep your receipts for anything even remotely relating to your work -- then consult a tax professional about what does and doesn't qualify. It definitely is worth it to pay an accountant, especially at first so you know how the game works.
Slashdot Mirror
the real question is -- are they going to support XMPP S2S (server to server federation)? Currently it looks like port xmpp.oscar.aol.com:5269 is NOT accepting connections (that's the XMPP S2S port).
Without S2S, this announcement is pretty much useless -- I mean, sure I can use my jabber client against AOL instead of the AOL-branded one, but I pretty much can do that already via the reverse-engineered joscar libraries (e.g. libgaim)
> Heck he might have actually believed that Linux was ripping off SCO's IP. No, really he didn't. Don't fall into that trap: having an open mind does NOT mean you never hold people accountable. Not everybody in the world is good, and in this case it is clear that Darl (and others) were trying to game the system for their own benefit. That said, shooting Darl is clearly not right. But he definitely needs to pay a significant personal penalty for this.
Why does DX10 rely on graphics card memory virtualization? What does it enable that I couldn't do in DX9?
The U-Bend isn't just for smell, it is also a safety issue: sewer gases can be poisonous or even explosive if allowed to collect.
http://en.wikipedia.org/wiki/Sewer_gas
People don't buy CFL's because they:
1) Don't look as good. Even the "warm" CFLs aren't nearly as comfortable to look at as an incandescent bulb.
2) Are generally incompatible with dimmers (there are some dimmer-capable CFLs, but they're few and far between)
3) Are ugly as sin in any fixture where the bulb is visible.
Zimbra is not just web based, it supports (open-source edition): POP,IMAP,WebDav as well as the Web Client
The paid-version of Zimbra supports:
MAPI (Outlook's native interface to Exchange), ActiveSync, and iSync.
You're absolutely right, because early-adopters (ie the Vista beta testers) don't matter at all to a product's success.
yes, I'm being sarcastic.
Except that the developer builds (and betas!) for Vista have been widely available both inside and outside of Microsoft for quite some time. As an ex-employee of MS, I'll bet you that at least 90% of the developers at Microsoft are running Vista on one of their boxes right now. So the "not out yet" excuse really doesn't hold water here.
The first 20 minutes of the new user's experience is critical in a consumer application like this. Requiring Joe Customer to go and download an update so that their brand new Zune works with their brand new PC is inexcusable.
I think the vulnerability isn't much of an issue for the intended use: protecting secure areas against infiltration. Sure, the Bad Guys (tm) could take them out from a distance, but the act of doing so would alert you to their presence.
This would free up a lot of manpower, since you don't have to have a person watching every inch of real estate -- it would be really useful for lessening the number of people you need to stay awake on "watch" while your platoon beds down for the night, or lowering the amount of manned guard towers you need along the DMZ. You still need real people to back up the machines, but you probably can get away with a lot less of them.
Sure, you could argue that a CCTV system does just as good a job of freeing up manpower, but I think the gun is a slightly better deterrent. I know from personal experience that I really am not that scared of sneaking past a closed-circuit camera, but I sure as hell am not going to try and sneak past this thing.
The difference is the margin of error. Basic scuba diving certification teaches you how to free ascend with no air from the deepest dive you'll ever make without a backup air source (~100ft: beyond that and you start doing things like taking a backup "pony bottle" air source). In a true panic situation where you can't swim up with the air you have left, you quick-release your weight belt, start blowing out (yes, blow out!), and your natural boyancy will take you to the surface -- without weight you'll go up pretty fast. Dropping weights is only for true emergencies -- usually you can just swim up since the air in your lungs will expand as you go up, making it surprisingly easy to ascend even from relatively deep dives without additional air.
Soo, to answer your question:
forgetting to check your compressed air: lose weight belt, feel stupid
forgetting to check your jet pack: crash and die.
Big difference.
It is important to note that the ACLU has only file a FOIA request at this point: they haven't filed expensive lawsuits or spent a ton of money yet -- so don't jump to complain just yet.
www.politicalcompass.org is definitely worth a read if you're interested in this whole Right vs. Left thing.
Actually you're missing something: I have a Macbook Pro, I run OSX primarily -- but I'd like the OPTION of occasionally running windows on the box, mostly so I can run PC-only games.
I never understood why he was CEO at A9...he's definitely a scientist and *not* a CEO type. I assumed that the weird A9-is-a-company-but-really-part-of-Amazon thing allowed him to do it: but I can't imagine it was the best use of him.
Most likely because there would be something in the "licensing agreement" to protect the patent holder from exactly this kind of thing....some legal language that basically says "even if the patents are found invalid, we still get to keep your money"
If the patent holder could be shown to have been working in bad faith (ie they knew the patent should not be valid, but were extorting the money anyway) then it is probably a different situation, but that would be a very difficult thing to prove.
As someone who's used quite a few web-based and client-based bug trackers over the years, I'll say that Bugzilla's web interface leaves a *LOT* to be desired: you are seriously limited in the complexity of queries you can write, your sorting options are laughable, general result layout is very poor, etc etc.
So I was prety excited when I saw this post - I downloaded the product and immediately tried it out. Unfortunately this product doesn't really add much: sorting is unimproved, the query builder is a little (not much) better, the layout and UI is unattractive and not signifcantly more powerful than the Web UI -- plus the product is pretty slow overall and consumes a frightening amount of system resources (150M memory, 300M VM space, according to TaskMan)
Overall, if this were a free product, I might use it: however for $99/seat it just isn't worth it right now.
Except that for print advertising, the SENDER pays the bulk of the costs (in the form of postage) wheras with electronic spam, the RECEIVER pays the cost (in terms of mail storage space and processing) --- therefore junk-snail-mail tends to be somewhat self-regulating, wheras junk email is not.
From TFA:
"Eagle is already in talks with a large networking company that is interested in handing out phones to its employees to learn how its organization really works, compared with how the company's organizational chart says it works."
This actually seems like a useful idea -- this kind of thing (tracking off-org-chart interactions in large companies) is something that has been studied and written about for a long time, and the cell-phone system seems like a really good way to do it. Neat.
The firware and filesystems use a number of tricks to ensure "wear leveling" between blocks so that there aren't 'really frequently written blocks' for the most part -- the blocks are all written fairly equally. In fact, this makes for interesting filesystems: filesystems which don't put control structures into well-known blocks, etc etc.
A quick Google search shows that on earth every square meter receives about 4.2kwh of energy per day over a 24 hour period.
A quick look at my electric bill says I use about 20kwh/day as a rough average -- another Google search suggests that the average US household uses approximately 25kwh/day
...So, finishing the math: using 15% efficiency solar cells, the Average US Household needs only 40 square meters (430 square feet) of solar cells to cover all its energy needs. Heck, I could use 5% solar cells on my roof in downtown San Francisco, and STILL have 2x extra capacity to sell back to the grid!
Don't get me wrong: Solar won't solve everything, particularly in applications like transportation where energy storage is an issue --- and cheap Fission IS something we should have figured out a long time ago --- but please don't resort to misinformation to make your points, it only weakens what you are saying.
Fair enough -- but the thing is that they'd end up looking like your specific packets and therefore would be relatively easy to filter at the ISP level.
The advantage of SSL is that it is a standard proto which is opaque: an ISP can't filter SSLed VOIP packets b/c there is too much legit SSL traffic that they'd also be blocking. As soon as you start using UDP, it becomes easier for an ISP to block it.
Unfortunately UDP cannot be run over SSL -- and UDP is a better protocol for many of these P2P apps in many situations: better firewall traversal, better performance when packets are lost (for audio and other 'real time' protocols, TCP's guaranteed ordering is quite a problem as it causes already-received packets to be buffered waiting for a previous retransmission), etc etc.
XML has some things going for it -- as a markup language for primarily text data (eg web pages) it works fairly well.
/> for example) and end up using a lot of memory and doing a lot of buffer expanding, or complex buffer-chaining stuff.
At a high level, XML is *CONCEPTUALLY* a great idea. I like the DOM programming model -- it is very expressive, and yet even complicated data tends to be understandable when represented as a DOM tree. Unfortunately, the basic text-XML representation that everybody uses is a terrible wire format from an efficiency and ease-of-programming perspective.
The real problem with XML is the massive inefficiency at the lower levels. XML is easily 2x-5x less efficient than comparable wire formats. For example I once worked on a project for an Instant Messaging server which used XML to communicate. I abstracted out the very lowest-level protocol layers so that they used simple XML token-compression and attribute-name compression....the result was a fully 400% increase in throughput through the server! This is primarily because the processor has so much less data to process (less string comparasins, string copies, etc) and therefore the memory bandwidth requirements are significantly lower.
Complexity of parsing is an issue as well. Writing a complete XML parser is full of subtleties and surprisingly difficult -- don't jump in and say otherwise unless you've actually done it. If you don't believe me, go look at how complicated something like the expat source or the dom4j source is.
A primary XML design goal (go read the XML designer's notes) was for ease-of-human-reading: this comes at the expense of efficient machine reading. Because data is not length-prefixed, and of arbitrary length, there are massive inefficiencies in buffering which leads to a lot of copying as you parse. There are never any "hints" in the protocol about what is coming up: and so parsers are forced to buffer things for an arbitrary amount of time (looking for that closing
Additionally, a text-based representation like XML is extremely inefficient for binary data. Having to parse through all of your data and escape/unescape special characters is yet another big performance hit.
A standardized and fully-supported binary XML representation would have a huge impact on the performance of things we use every day -- and it could all happen at the low levels without even touching app-level code.
Running Cat5 between buildings can be quite a problem, depending on the distance and such: lightning strikes or even small ground potential differences between buildings can destroy ethernet equipment. Remember, copper ethernet equipment is designed for very low voltage and even a small current flow can cause serious damage. Wireless is almost certainly a better bet for what you want.
If they advertised the position as full-time, and then are trying to do a bait-and-switch for contracting: don't buy it. Is this the kind of place you want to work for? Do you really believe them when they say they'll move you to full-time? What credibility do they have at this point?
In all my years as a hiring manager, I've never had a situation where I advertised a position and then "couldn't get approval". You don't advertise the position before you get approval. There *are* situations where I meet a candidate and interview them for one position, realize they aren't a good fit but decide I still want to hire them into the organization -- in those situations I might offer them a contracting role with the hope of getting a full-time spot: but I am always very clear that this is a different position than the one they came in originally for.
If you do decide to take the job, remember that the tax rates are often higher and you'll need to cover things like benefits, etc. Contractor should be _substantially_ higher than a full-time salary (say 40-50% higher as a guess, but definitely research that # more). Saving for retirement will also cost you more: look into things like a SEP IRA or a traditional IRA.
When you're working as a contractor, make sure to keep track of your expenses, keep your receipts for anything even remotely relating to your work -- then consult a tax professional about what does and doesn't qualify. It definitely is worth it to pay an accountant, especially at first so you know how the game works.