No, that's not the way it works.
on
Cracking OSX
·
· Score: 2
QNX holes have shown up on BugTraq/Securityfocus.
I hear this a lot. Linux users are always telling me "there are fewer exploits for OpenBSD because fewer people use OpenBSD", which is like saying "There are fewer fatal car crashes involving Volvo's because fewer people drive Volvo's".
IOW, you are half right.
But not everybody who hunts exploitable holes is a black hat, there are people (such as myself) who hunt for bugs in any OS or software they use. I'll even write exploits- not to hack other systems, but to pressure the vendor to fix the problem and ensure that *MY* systems are not exploitable by others...
The name "coke" is a Trademark of Coca-Cola, but ONLY when used in reference to a beverage. I could choose to register 'coke.net' for my fossil fuel's distribution company, and it is unlikely that Coca-Cola could do anything about it.
It is unreasonable to give major corporations first dibs on names in TLDs unrelated to their primary area of business.
In general, with the exception of certain 'famous marks', a trademark applies only to one specific market.
I may hold the trademark for "Ferret's Bookstore", but that would only give me ownership of the domain "ferret.books" , not first dibs on "ferret.com" or "ferret.shop" or "ferret.xxx".
Before suggesting that an international organization take pains to protect American trademerks, first consider the definition of a "trade" "mark", and how a registration for a specific term used for a specific market in a specific locality applies to a global naming system.
There is a huge difference between 'have the ability to compress randomly occurring data' and 'have the ability to compress the specific file Mike supplies'.
It is impossible to write a routine that can losslessly compress every possible 3-megabyte file that could ever be generated.
It is not impossible to write a routine that can compress the one specific file that Mike supplied to you. That is, it is quite likely that you could write a program that can losslessly compress that one single input set, such that:
length of decompressor) + (length of compressed data)
Why, he'd just reverse engineer the
decompressor, patent it, get rich, and buy an island inhabited with young bikini clad virgins before
the your check had even cleared.
That would only be true for the general casse compressor-decompressor. I could write a routine that would work for that one specific input file, but fail miserably on any other input. This would win me the $5K, but be valueless for any other purpose.
econdly, i've been thinking about this problem for about 3 years now.:) I've tried so many
methods and ways of interpreting and looking at random data, i'd have enough to write a book if i'd
bothered to keep accurate logs. If i had $1 for every time i said "I'VE GOT IT!" i'd probably have
$5000 already. Well, maybe that's a tad off the mark, but anyway, you get my point. Right, onto my
conclusion...
The mistake both you and Mike make is that while writing a program for the general case of compressing random data is impossible, it is very different than writing a program to compress one specific file of 'random' data.
The quest was for 'Lossless data compression', but the challenge was presented backwards-
Given a sufficently large source file of truly random data, I can create a binary and a data file which can recreate that one specific source file, losslessly, with my binary+data being smaller than the source. That is, I can create a routine that will work for just that one specific source file, no others.
The problem of 'Lossless Data Compression' refers to the opposite case- given any general purpose routine to compress files, I can create a file that it cannot compress. That is the oppposite of the challenge given, and actually is impossible.
As stated, even with the restriction of a single compressed file, the challenge *IS* winnable.
The challenger was mistaken, he thought that he was offering an impossible challenge, but was mistaken.
The comp.compression fact discusses that for any given compression algorithm, it is possible to craft an input fill that cannot be compressed.
This is different than the challenge proposed, where Mike, the challenger, provided a file of size X, and Patrick, the challengee, was required to provide a de-compression program of size Y and a data file of size Z, where X > Y+Z.
The difference here is that Patrick was allowed to hand-craft the compression method to the data file, but Mike was not allowed to hand-craft the original data to the compression routine.
Basically, Mike was wrong, and should pay the $5K.
Read the entire file. The challenger agreed that the entry could use multiple files:
=== Begin quoted text ===
>
> I meant can I send you a compressor and several compressed files whose
> total file size is less than the original uncompressed file and from
> which I can regenerate the original uncompressed file
>
> Patrick
Sure -- but you send me a *decompressor*, I don't need the compressor.
I've seen cabinets show up dirt cheap on the used market, at business auctions, in the University spare furniture redistribution, etc.
Rackmount PC hardware is still expensive, but rackmount fullsize cases aren't all that pricey- the real money goes for systems optimized to use as few rack-inches as possible.
And when adults are herded into buildings and forced into involuntary association with each other (prison, etc) they revert to the same behavior patterns...
My girlfriend has an ex-boyfriend that is very threatening, and
we live in fear that he may one day corner her as she's leaving work (she's a manager at a restaurant and typically closes up, meaning she leaves later than everyone else)
She (not you) needs to do something about this. Start a paper trail with the police, carry pepper spray, start taking training for a concealed carry permit (if you live in one of the 32+ states that are 'shall issue').
To sit there and say 'well, this guy might kill me someday, oh well' is no way for adults to live.
As mentioned before, the server (jabberd) builds and runs cleanly on FreeBSD and Solaris, and actually scales much better on either of those than Linux.
This isn't "fringe" this is a platform-agnostic open source project that will compile and run on any supported platform with little or no effort.
The only thing 'linux-centric' about jabberd is the insistence on using gmake. (The 'gabber' client is a whole other story, I've never gotten recent versions to run anywhere.)
Generally, ISPs will run their own local server with logins for their own customers as a value-added service, and allow anybody remote to message them.
While 'Instant Messaging and Presence' is the first application of Jabber, they have a much more ambitious goal- at it's core Jabber is a threaded XML router that just happens to work really well as a chat server.
There are already several Jabber-related projects only tangentially related to instant messaging, and there are many other interesting applications for XML routing on the horizon.
Jabber has come a long way in the last six months, but it's downfall is likely to be the scarcity of legible documentation.
What little there is can be found on docs.jabber.org
It's a real struggle getting a server compiled and running with even the most basic of functionality, and many of the most interesting value-added features have little or no documentation.
There is an active development community on the JDEV mailing list and 'jdev@conference.jabber.org' channel, but like so many other open source projects out there, 90% of the developers are busy writing cool features, with really only Peter Saint-Andre (aka 'stpeter') putting any real effort into documentation.
A lesser problem is what some call 'fascination with the technology', and is a cause of the lack of users- most Jabber users are developers and admins who are more interested in playing with the new technology for it's own sake than as a way to communicate. Basically, 180 degrees from the motivation of the average AIM user.
The majority of the problems you mention (except for the MSN issue) are client issues in JabberIM.
What is particularly annoying is that JabberIM is the client produced by Jabber.Com, the "commercial" side of the Jabber development team. If any client was going to work reliably, one would hope that would be the one.
If you have any funds to spend on doing this right, and any interest in your insurance company paying out if your rack goes up in flames, do this right...
Supports serial control, and has built-in ethernet with SNMP, HTTP, telnet access. You can assign individual usernames and passwords with access to any one or a group of outlets. SNMP traps on invalid passwords or SNMP community strings so you can detect hacking attempts.
The rules for Robot Wars weapons limit how destructive a robot can be, and the design of the challenges make 'destructive power' a lower priority.
This is as opposed to Battlebots, where the sole challenge is to outlast or disable the opposing robot.
I've seen most of the Robot Wars episodes that PBS has shown over the last two years, and I don't recall any bot with real damaging weapons except the house robots. The rules forbidding hardened steel really cripple Robot Wars weaponry.
We're a Not-For-Profit ISP, I just got SDSL pricing from a local DSL provider that charges rates more in line with their actual cost to provision the service. It is _not_ cheap.
These prices are strictly for delivery to an ISP, they do not include internet bandwidth, or the ATM DS3 circuit ($1K/month)
ADSL: $75 per month per customer, down to around $40 with several thousand customers.
SDSL at 1.5Mbps: $250 (down to $150 on volume)
SDSL at 768: $200 (down to $100 on volume)
Notice that they cheapest possible ADSL rate is $40/month, which means that even without including the cost of internet bandwidth this is more expensive than your average bargain basement DSL provider.
There is oversale on DSL connections, it's just hidden slightly better.
You may have 1.5M/568K to the DSLAM at the local central office, but from there all the DSL customers on your carrier are aggragated on a single pipe (usually DS3 or better on a fiber ring) where the traffic is carried to the DSL provider's primary switch. This can be a choke point.
From there, traffic for all of the DSL customers of a given ISP is consolidated into an ATM connection (one PVC per customer, or a single PVC for all customers) where it is delivered over DS1 or DS3 to the ISPs DSL edge router. This is another point where capacity can be oversold. The ISP can 'overcommit' this circuit, provisioning a dozen DSL customers on a single T1 circuit that can barely handle the full outbound bandwidth of just one customer.
Lastly, the ISP can overload the CPU and bandwidth on their DSL edge router, their core routers, the segments that connect them, and the connection to their upstream providers.
Every commercial ISP and every DSL provider oversells their available bandwidth- it's the only way to make a profit at the low rates they charge.
If the oversale is reasonable (3-10x actual capacity) and most customers don't use their potential bandwidth, then nobody complains.
Our Not-For-Profit ISP coop sells bandwidth to the members at cost, and it is not cheap- from 60-85 cents per kilobit.
That is the true cost to get bandwidth to the core router at any Tier-3 ISP. Then there is the additional cost for the DS3 circuit and per-user payments to the DSL provider.
Your ISP, your DSL provider, they all stay in business only because they oversell their bandwidth and their connectivity.
They depend on customers who pay the full rate and use almost no services to subsidize the power users who cost the provider vastly more than they pay.
Slashdot Mirror
I hear this a lot. Linux users are always telling me "there are fewer exploits for OpenBSD because fewer people use OpenBSD", which is like saying "There are fewer fatal car crashes involving Volvo's because fewer people drive Volvo's".
IOW, you are half right.
But not everybody who hunts exploitable holes is a black hat, there are people (such as myself) who hunt for bugs in any OS or software they use. I'll even write exploits- not to hack other systems, but to pressure the vendor to fix the problem and ensure that *MY* systems are not exploitable by others...
It is unreasonable to give major corporations first dibs on names in TLDs unrelated to their primary area of business.
In general, with the exception of certain 'famous marks', a trademark applies only to one specific market.
I may hold the trademark for "Ferret's Bookstore", but that would only give me ownership of the domain "ferret.books" , not first dibs on "ferret.com" or "ferret.shop" or "ferret.xxx".
Before suggesting that an international organization take pains to protect American trademerks, first consider the definition of a "trade" "mark", and how a registration for a specific term used for a specific market in a specific locality applies to a global naming system.
It is impossible to write a routine that can losslessly compress every possible 3-megabyte file that could ever be generated.
It is not impossible to write a routine that can compress the one specific file that Mike supplied to you. That is, it is quite likely that you could write a program that can losslessly compress that one single input set, such that:
That would only be true for the general casse compressor-decompressor. I could write a routine that would work for that one specific input file, but fail miserably on any other input. This would win me the $5K, but be valueless for any other purpose.length of decompressor) + (length of compressed data)
The mistake both you and Mike make is that while writing a program for the general case of compressing random data is impossible, it is very different than writing a program to compress one specific file of 'random' data.
Given a sufficently large source file of truly random data, I can create a binary and a data file which can recreate that one specific source file, losslessly, with my binary+data being smaller than the source. That is, I can create a routine that will work for just that one specific source file, no others.
The problem of 'Lossless Data Compression' refers to the opposite case- given any general purpose routine to compress files, I can create a file that it cannot compress. That is the oppposite of the challenge given, and actually is impossible.
As stated, even with the restriction of a single compressed file, the challenge *IS* winnable.
The comp.compression fact discusses that for any given compression algorithm, it is possible to craft an input fill that cannot be compressed.
This is different than the challenge proposed, where Mike, the challenger, provided a file of size X, and Patrick, the challengee, was required to provide a de-compression program of size Y and a data file of size Z, where X > Y+Z.
The difference here is that Patrick was allowed to hand-craft the compression method to the data file, but Mike was not allowed to hand-craft the original data to the compression routine.
Basically, Mike was wrong, and should pay the $5K.
Read the entire file. The challenger agreed that the entry could use multiple files:
=== Begin quoted text ===
>
> I meant can I send you a compressor and several compressed files whose
> total file size is less than the original uncompressed file and from
> which I can regenerate the original uncompressed file
>
> Patrick
Sure -- but you send me a *decompressor*, I don't need the compressor.
=== End quoted text ===
Rackmount PC hardware is still expensive, but rackmount fullsize cases aren't all that pricey- the real money goes for systems optimized to use as few rack-inches as possible.
If all else fails, you can buy threaded rack rails and build your own cabinet around them.
Okay, there is one other reason- it reduces the likelyhood of her being charged when she shoots him as he is trying something :-)
And when adults are herded into buildings and forced into involuntary association with each other (prison, etc) they revert to the same behavior patterns...
She (not you) needs to do something about this. Start a paper trail with the police, carry pepper spray, start taking training for a concealed carry permit (if you live in one of the 32+ states that are 'shall issue').
To sit there and say 'well, this guy might kill me someday, oh well' is no way for adults to live.
However, the new "web client services" shows some promise.
This isn't "fringe" this is a platform-agnostic open source project that will compile and run on any supported platform with little or no effort.
The only thing 'linux-centric' about jabberd is the insistence on using gmake. (The 'gabber' client is a whole other story, I've never gotten recent versions to run anywhere.)
It's a problem with most open source projects- writing features is sexy, writing manuals is not.
Generally, ISPs will run their own local server with logins for their own customers as a value-added service, and allow anybody remote to message them.
There are already several Jabber-related projects only tangentially related to instant messaging, and there are many other interesting applications for XML routing on the horizon.
It's a real struggle getting a server compiled and running with even the most basic of functionality, and many of the most interesting value-added features have little or no documentation.
There is an active development community on the JDEV mailing list and 'jdev@conference.jabber.org' channel, but like so many other open source projects out there, 90% of the developers are busy writing cool features, with really only Peter Saint-Andre (aka 'stpeter') putting any real effort into documentation.
A lesser problem is what some call 'fascination with the technology', and is a cause of the lack of users- most Jabber users are developers and admins who are more interested in playing with the new technology for it's own sake than as a way to communicate. Basically, 180 degrees from the motivation of the average AIM user.
What is particularly annoying is that JabberIM is the client produced by Jabber.Com, the "commercial" side of the Jabber development team. If any client was going to work reliably, one would hope that would be the one.
Download your own copy of the root cache file and you have all the functionality of the internic "root zone" and then some.
Something like the APC MasterSwitch, for about US$60/outlet.
Supports serial control, and has built-in ethernet with SNMP, HTTP, telnet access. You can assign individual usernames and passwords with access to any one or a group of outlets. SNMP traps on invalid passwords or SNMP community strings so you can detect hacking attempts.
With the wireless modules, anybody driving past your house can power down your systems remotely. Not exactly a feature to be proud of...
This is as opposed to Battlebots, where the sole challenge is to outlast or disable the opposing robot.
I've seen most of the Robot Wars episodes that PBS has shown over the last two years, and I don't recall any bot with real damaging weapons except the house robots. The rules forbidding hardened steel really cripple Robot Wars weaponry.
These prices are strictly for delivery to an ISP, they do not include internet bandwidth, or the ATM DS3 circuit ($1K/month)
ADSL: $75 per month per customer, down to around $40 with several thousand customers.
SDSL at 1.5Mbps: $250 (down to $150 on volume) SDSL at 768: $200 (down to $100 on volume)
Notice that they cheapest possible ADSL rate is $40/month, which means that even without including the cost of internet bandwidth this is more expensive than your average bargain basement DSL provider.
You may have 1.5M/568K to the DSLAM at the local central office, but from there all the DSL customers on your carrier are aggragated on a single pipe (usually DS3 or better on a fiber ring) where the traffic is carried to the DSL provider's primary switch. This can be a choke point.
From there, traffic for all of the DSL customers of a given ISP is consolidated into an ATM connection (one PVC per customer, or a single PVC for all customers) where it is delivered over DS1 or DS3 to the ISPs DSL edge router. This is another point where capacity can be oversold. The ISP can 'overcommit' this circuit, provisioning a dozen DSL customers on a single T1 circuit that can barely handle the full outbound bandwidth of just one customer.
Lastly, the ISP can overload the CPU and bandwidth on their DSL edge router, their core routers, the segments that connect them, and the connection to their upstream providers.
Every commercial ISP and every DSL provider oversells their available bandwidth- it's the only way to make a profit at the low rates they charge.
If the oversale is reasonable (3-10x actual capacity) and most customers don't use their potential bandwidth, then nobody complains.
That is the true cost to get bandwidth to the core router at any Tier-3 ISP. Then there is the additional cost for the DS3 circuit and per-user payments to the DSL provider.
Your ISP, your DSL provider, they all stay in business only because they oversell their bandwidth and their connectivity.
They depend on customers who pay the full rate and use almost no services to subsidize the power users who cost the provider vastly more than they pay.