No, manufacturers hold one key to solving this: if they would print in bold letters on a bright red label on the outside of the box, "WARNING: THIS PRODUCT BROADCASTS YOUR NETWORK (INCLUDING PR0N SURFING) TO ANYONE WITHIN ONE QUARTER OF A MILE", it would help.
Actually the distribution is exponential...one person uploads N copies to the P2P network...then N people upload their copy to N others each...etc.
So assuming that everyone uploads to exactly one other person on their 56K modem, we have about 22 iterations (44 days at 56K, 700 MB per day) before 4 million people have both movies. That's still much more than a weekend.
More realistic numbers: the movies are actually about 350MB in size (total 700MB, or one day at 56K), everybody uploads to four others, and the network speed is 256kbits (64kbits/person). Now we have 4 million people served in a mere 11 iterations, each iteration taking a mere 6 hours--a little under three days for the whole thing.
Most people who have broadband have some kind of asymmetric arrangement, and the two movies are separate entities, which means we can assume that everyone who's downloading is talking to two people who are uploading, and they are transferring both movies at the same time. This cuts the iteration time down to three hours, which makes the whole thing fit nicely (if only theoretically) into a weekend.
Typical sizes for movies soon after theatrical release are 350-400 MB, in DivX format. This is for a crappy camcorder version. 700MB+ VCD movies don't arrive until some time later--it takes a little longer because the physical film has to 'disappear' for a few hours.
so 700 MB times 4 million = 2.6 petabytes, or 9000 people with cable modems using 30% of their bandwidth each for a month.
OK, a medium-sized CRT-based TV set consumes ~100 watts of power. Much of that power is radiated as heat and light, but a good chunk is radiated as a really powerful electromagnetic signal that can be converted back into an image for hundreds of yards, and parts of the signal (especially vsync) can be detected for *miles*. Simply put a trace signal on some channel and listen for anyone watching it. The equipment for full image recapture costs a few tens of thousands of dollars but it is well within the budget of a multi-million dollar cable company. A simple vsync detector is two orders of magnitude cheaper.
You can defeat this method by using an LCD display device, or by recording everything on cable and watching it at some other time (and frankly, I would do that in any case just to avoid commercials).
I've run ReiserFS against ext3 head-to-head (redundant servers, mirrored data, load-balanced services, hardware as identical as it gets) since 2.4.10 or so. For 8 years prior to that, I've run ext2 on hundreds of Linux boxes. Crashes, corruption, software bugs, memory defects, bad sectors, overheating RAM, viruses...I or my clients have seen it all.
When it works(*), reiserfs and ext3 are nearly identical in terms of performance and reliability, except for some corner cases with data appended to files close to an unclean shutdown (ext3 discards uncommitted data, while reiserfs (and ext2 for that matter) puts garbage at the end of the file). Of course, if you have a directory structure that obviously favours ReiserFS (flat namespace or small files), then reiserfs may be faster; however, for typical Windoze/Linux file service, the advantage or disadvantage of ReiserFS is negligible.
Now for the (*): Murphy works at your company. Things will always go wrong, be they due to human failure, hardware failure, or software failure. When ext3 goes wrong, you can apply e2fsck (a very fine although still somewhat imperfect automated recovery tool), debugfs (a very fine hand-reconstruct-your-filesystem-tool), some third-party data recovery tools (open-source and proprietary), and the filesystem structure is sufficiently straightforward that you can easily recover most lost data "by hand" if you can't get it back from any of those.
Of course backups are part of any good data recovery strategy; however, it often comes down to a choice between spending 20 days restoring data from tape, 36 hours waiting for reiserfsck, 54 hours waiting for rebuild-from-scratch from a mirror server, or six hours recovering 99% of it with ext2 recovery tools. The ability to crawl through the filesystem looking for data is as important as any other data recovery strategy.
ReiserFS has data recovery tools which--in their own documentation--say "these tools are only of beta quality." reiserfsck simply cannot recover from several common kinds of filesystem corruption. The data structure of a reiserfs tree is a balanced tree with very little predefined structure--unlike ext3, in reiserfs you can't just search all inodes to look for files that have disappeared from any directory. If a reiserfs interior tree node is lost, a few percent of your filesystem at random will become inaccessible--contrast with a damaged ext3 block, which at worst loses a few dozen files, or loses filenames but without affecting the contents of the files. A full-blown tree-reconstructing reiserfsck involves reading the entire filesystem volume (or at least the nominally occupied parts of it) more than once, and there is no guarantee it will be successful.
Another important distinction between reiserfsck and e2fsck is that e2fsck will leave you with a usable filesystem, even if the data within is corrupted--that is, you'll be able to store new data on the filesystem safely. reiserfsck will not leave you with a usable filesystem in common cases--you'll either have to live with inaccessible storage, or rebuild the filesystem from scratch.
My current recommendation to clients is to use reiserfs only for workloads where recoverability of data is not a requirement--e.g. filesystems for squid caches, or mirrored servers, where it is acceptable to respond to filesystem corruption by starting over from mkreiserfs. In other cases, where e2fsck after a reboot is unacceptable use ext3, otherwise use ext2. Other filesystems are too new or too slow to care about.
Frankly, the only currently available, mature, robust filesystem with proper, well-supported tools on Linux is ext2--fsck's and all. Everything else is just a tool for discovering bugs the hard way.
These patents, if granted, will become the property of a legal person (corporation). This is VERY dangerous. The danger arises when the person might lose control over the patents.
It would seem to me that all a large company would have to do to get unlimited access to these patents is to start suing RedHat (it doesn't matter what for, and it doesn't have to be related to patents at all, as long as the legal costs of defense are mandatory and large) until Red Hat runs out of money, then show up when Red Hat's assets are sold at bankruptcy auction and walk away with a government-regulated monopoly on some useful pieces of free software.
This would result in the unfortunate situation that a critical component of certain free software might be held by an entity that refuses to license it on any but the most draconian terms.
Red Hat is (comparatively) well-funded for a Linux vendor. Smaller corporations shouldn't even attempt to play patent games, because the only two possible outcomes are 1) be ignored, or 2) lose everything.
Oh! Oh! Oh! Can we send Valenti into low Earth orbit without all the bulky space suits, oxygen supply, and stuff? Think of the savings in launch fuel costs!
I have done a security audit for a company that isn't Microsoft, but wants to be (don't ask, it's really sad). I'd like to say that I had help, but I didn't. Kids, don't try this kind of software project management at home.
The thing about commercial software development (open-source or otherwise) is that the population of developers is small, and their schedule does not allow them to develop their coding style very much. As a result, you can usually recognize who wrote which code after you've read enough of it, and once you can do that, you can predict the quality of their future code based on past code.
The thing about security bugs in code that has NEVER been audited before is that most of them (by number) are the same basic stupid mistakes repeated over and over again.
Exploiting this to its full potential, you can find security holes with 'find' and 'grep'. In my case, about 250 security holes per hour (20 seconds of computer time, 3580 seconds of looking at the code in question and eliminating cases where calling or enclosing code prevents exploitation of dangerous code) in 275 KSLOC during the first day of auditing. This rate drops off to about 120 "hits" per search with maybe a dozen false positives (interestingly enough the false-positive rate always hovered around 10%), for a total of just over 1000 security holes in a single week.
After I made that pass, where I might be finding and even fixing multiple vulnerabilities in a single *minute*, I then look at who wrote the code I am fixing, who mentored them, who they mentored, etc. Basically I construct a picture from the corporate organization, the revision history, and the code, to find out who the bad coders are--then I audit everything they ever touched. This finds bugs of all kinds, but not all of them are security-related. There are still dozens of security bugs found per day using this search strategy.
Another search tactic is to do global source code searches for the variable names in functions I am fixing, and for the syntactic structures (i.e. everything around the variable names). This finds an amazing amount of plagiarization, as well as code examples that might have originated from corporate training or "learn language_X in N days" books and which were cut + pasted without any further thought about issues like checking for error returns or invalid inputs.
Note that the vast majority of the bugs found were the Unix equivalent of taking a string from an untrusted entity, blindly sprintf'ing it into an automatic array variable, and feeding the result to system() -- three different security holes in as many lines of code. This is probably also true of Microsoft code--thousands upon thousands of instances of a handful of problems, over and over again.
Simple bugs require only a few seconds to fix, especially if you are looking at repeated errors made by the same coder, and you've already worked out a general solution. Other bugs require more time, but very few bugs require more than a few hours to fix--instances where a redesign is required are very rare, and often this kind of problem is discovered by other means (e.g. by looking specifically for network servers or programs that run setuid, instead of searching for dangerous code fragments). The average time required is MUCH less than 8 minutes per line of code--it's actually closer to 8 minutes per bug, and 4 bugs per KSLOC.
Assume an average bug rate of one bug per 500 lines, and an average review rate of 8 minutes per line, I'd have 4000 minutes per bug for analysis and repair. That is plenty of time to get rid of 99% of the bugs--I spent less than 4000 minutes on my entire audit, and given 4000 minutes per bug I could learn a new programming language for each one!
This kind of audit certainly does not fix all problems--the security holes that were found after the release of the code I audited attest to that. Audits like this don't produce perfect results, only better ones--half a dozen exploitable vulnerabilities are much better than a thousand.
This is what we can expect from Microsoft: fewer stupid vulnerabilities in the short term, fewer bad design decisions in the long term, with no noticeable impact on the more sophisticated attacks in any amount of time.
Incidentally, I also did an audit of a Linux distribution using more or less the same technique. I found that about 90% of the programs in/usr/bin matched patterns that suggested vulnerability, but fewer than 10% of the programs actually had exploitable vulnerabilities upon closer inspection. Most of the vulnerabilities were/tmp file-creation/symlink attacks, and many of the holes required the attacker to have very much control over the victims' activities to exploit.
Some time after I did the Linux audit, Linux distribution vendors started taking security seriously. Now when I audit Linux programs I'm pleasantly surprised to discover that they are already hardened against/tmp-style exploits and buffer overruns, even when it is provably not necessary for security.
I think that people who moan that Unix should be more like Windows or Mac don't really understand Unix, or Windows, or Mac.
XML is part of the problem--people who think XML is the solution, or even neutral, are suffering from a specific kind of delusion
which I'll cover in more detail later.
Advocates of auto-detection instead of manual configuration I'll deal with right now: Applications in certain problem domains require
explicit human-supplied configuration data. This is unavoidable in any application that has to implement some choice of policy, especially
security policy. There are some things you can't ever autodetect, so if you can't configure the application, then you need many different
applications, each hard-wired for one possible desirable configuration. Certainly a lot of things that should be auto-detected are not,
but auto-detection will not eliminate the configuration problem.
Windows and Mac are platforms controlled by a single vendor. That vendor has a _lot_ of influence over how applications are
designed for that platform. When the vendor designs and implements the platform, the vendor will (intentionally or otherwise) reward
applications with an architecture consistent with the vendor's design, and penalize those that don't. Applications tend to comply
with the vendor architecture because the cost of non-compliance is greater than the cost of compliance.
Unix is not a platform controlled by a single vendor. Heck, it's not even a platform; it's a bunch of little standards that
were chosen arbitrarily and stitched together. Linux, FreeBSD, SysV, BSD, Solaris, QNX, HP/UX, etc. are not Unix platforms--they are
platforms compatible with Unix, implementing parts of the SUS, ANSI, and POSIX standards, with varying degrees of completeness and
success. As such, there is no reward for making an application's architecture consistent with the OS vendor's design; contrariwise,
there is a compelling reward for an OS vendor to make an OS architecture consistent with a desirable class of application.
The difference is critical for understanding the configuration file nightmares of both kinds of platform. Windows has a really awful
configuration mechanism that nobody would ever use if they weren't compelled to; however, certain parts of Windows are only conveniently
accessible via this configuration file format, easy (if not reliable) methods to access the format are provided to all developers and
available on all end-user machines, and the configuration schema does not define a lot of policy to get in the way of extensions (need
new schema? Add a new DLL!). The Mac has a different architecture and mechanism with the same consequences.
On the other hand, applications that run on Unix are, in whole or in part, designed for "other" systems. Applications that were
designed and written exclusively on Unix-like platform X eventually get ported to some other Unix-like platform Y--those that don't
tend to be eventually replaced by similar applications that do. When this happens, the resulting application is an alien on both
platforms. The application must find everything it needs on each target platform, or it must bring with it those things that are missing
from some target platforms. This means that the application will have translation or interpretation layers (all C apps have at least
one translation layer in the C compiler) and replacements for missing functionality in the target platform.
Now for the delusions. New code written in a language with link-level compatibility with a free, small, fast, easy to use in code, portable,
robust configuration mechanism library will have no problems. Note that the status quo is already as free, small, fast, easy to use in code, portable,
and robust as it needs to be for applications that already use it, so alternatives which are not all of these do not merit discussion.
However, there are constraints imposed on this hypothetical library by legacy code:
It would have to be already installed or available on all Unix-like systems with bindings to all Unix-like languages,
which rules out nearly everything invented after 1978. Otherwise, every application (and language!) must bring either a copy
of the library or their own code. Strangely enough, "open file," "read text line," and "lexically analyze this string" primitives
are implemented in nearly all Unix-like languages, and interactive text file editors are shipped on nearly all Unix-like systems...
It would have to be as small and fast as fgets+scanf, or a lex+yacc parser, otherwise it will hurt performance or have
a large footprint, and people who care about performance or size won't use it. XML can't do this unless you drop the i18n and
character entity and encoding support--at which point it's not really XML any more.
It will have to use small ASCII text files for persistent storage, otherwise you have to implement and force everyone
to use either your own editing mechanism (aka "a control panel DLL"), or you implement and force everyone
to use replacements for Unix filesystem-crawling tools which allow you to selectively access the data (aka "the registry and
regedit", or "replacements for cvs, vi, find and grep")--both of which violate the "once and only once" rule since these
facilities exist already in Unix and they are used for this purpose.
It will have to be used directly by the actual applications--otherwise you violate the "once and only once" rule
by having either two configuration files and two applications (the real application, and a configuration application), or two
configuration file handling mechanisms in one application (for old-style and new-style config files).
It might be possible, given overwhelming demand, to convince maintainers of significant mature legacy code to adopt the new configuration
mechanism, if the XML-based mechanism is more widely ported and better debugged than their own configuration-management code. Good
luck, and be prepared to do the work yourself many, many times over until you either change their minds, or they leave the project and
you're stuck maintaining the code by default.
Note that other standardization initiatives, like FHS or the LSB, involve relatively superficial changes which application maintainers were
probably willing to make anyway. The FHS and LSB ask application maintainers to change the parameters to a few system
calls without affecting the architecture of any part of the application or the semantics of its operation. For example, the application may
open()s a file, but after the FHS is implemented that file has a different name. Both names are constant strings, the file is still opened
for reading, and it still has the same contents with the same syntax and semantics. A one-line change and a recompile brings the application into compliance, and in an emergency, a symlink will make the application work.
Other initiatives, such as DNS and PAM, are usually facilities that are not intrinsic to applications. Host name resolution or user access verification involve resources shared by many applications, and there is a real technical penalty for non-compliance.
Changing the way applications handle configuration is a large architectural change--you're asking people to replace open(), read(),
close(), and some code which is intrinsic to the application with new functions that have different semantics, and may even have to be
called at different times. Expect resistance.
The only hope of this ever happening in real life is for a Linux distributor to decide to implement it, and contribute the work to achieve it.
Said vendor will have to hack and slash their way through hundreds if not thousands of packages to bring them into compliance. Once all
of that is done, all the upstream package maintainers will have to integrate the changes--or all the other Linux vendors will have to
repeat the hack-and-slash job.
Re:Good for some, nightmare for others
on
Peek-a-Boo(ty)
·
· Score: 1
It seems you're doing something wrong...where I work, the only access to the outside world is via the proxy; changing proxy settings to other values will result in loss of Internet access because values other than the ones prescribed by the company don't work.
Internal relaying is irrelevant because sooner or later all relays must go through the One True proxy to outside. PB doesn't really change that situation.
PB does allow an internal machine to co-operate with an external machine to make content more difficult to automatically classify (e.g. by disguising the URL so a URL filter won't work, or encrypting or transcoding the data so a content filter won't work). This is nothing new; there have been public web mediator sites for working around content filtering restrictions since probably a few hours after the first content filter was deployed, and PB is just another one. Maybe PB makes it easier to find many new open relays. Whee.
The only way to have secure content filtering is to maintain a white-list of sites, lock down all those sites plus the DNS and low-level communications paths between them and your content-filtering proxy, and deny all other traffic. This works but you need a content control officer to add each new approved site, and the security of the entire arrangement is equal to the security of the easiest site to crack. It does work well for things like promotional kiosks in stores, where you only want users to access your own web site.
Any other arrangement, even one that analyzes content, just leads to an arms race between deny rules, open proxies, and co-operative external mediators. IMHO this whole thing is a waste of time except for fixing very short-term problems (e.g. someone idiot starts 500 simultaneous mp3 downloads, so you block that site just long enough to apply a cluebat to the user).
It's usually a lot more effective to have people agree to a usage policy, then log traffic and discipline and/or fire people after the fact. You can kill off anything PB-like with a generic "no traffic we don't approve of or can't analyze" prohibition combined with logging.
3) Toolkits should be double-buffering everything, using client-side layout code (rather than X window objects), and holding all drawing until input events have been handled.
A lot of X toolkits are very dumb; they are little more than event loops wrapped around libX11 and maybe libXt. Many of the less-heavily-optimized toolkits don't bother collapsing events, or they make it difficult for applications to use such optimizations. Some toolkits leave redraw of non-widget objects entirely to the application, and most application authors are not going to bother writing proper minimal-refresh code, especially if the objects are simple enough that the delay for a full redraw on every expose event is tolerable.
In the worst cases (i.e. most of them, it seems), applications redraw _everything_ if _any_ part of their visible area is exposed, and the only optimization done is window clipping by the X server.
This is actually a problem in Windoze too, if an application is written the same way. Big/complex Windoze apps assign teams of people to fix their refresh bottlenecks, or they render everything double-buffered and do screen updates by bitblitting, or (ugh) they have a high-priority thread that just does screen updates while the low-priority threads do all the actual work, so the application _looks_ fast, when in fact it is slow.
Take a look at the implementation of Gtk or Tk canvas objects to see what hoops you have to jump through to get smooth updates of complex graphic objects. Also take a look at how fast you can resize windows owned by these objects. Then look at applications designed for lesser toolkits and see all the duplication of effort this leads to.
Low-latency is just that--the kernel tries to keep the latencies lower than whatever you're comparing it to. The same kernel A may be low-latency when compared to kernel B, but A may be high-latency when compared to kernel C.
Realtime is a boolean attribute: either you're realtime, or you're not. A realtime kernel specifies the maximum and maybe the minimum latency for various requests.
These two attributes are orthogonal: a kernel may be low-latency but not real-time, vice-versa, both, or neither.
For example, a real-time kernel may guarantee that you'll get to do one disk read per second (as long as the disk hasn't completely failed, the kernel hasn't crashed, etc). It might make the guarantee stick by ALLOWING only one disk read per second, even if the disk is idle 99% of the time, and your disk is doing absolutely nothing for 999.9ms between consecutive read requests. Not low-latency, but certainly real-time.
A low-latency kernel may allow read requests to complete as quickly as possible, but it may not guarantee a maximum time for read requests to complete. So your application will be able to start executing 100ns after a read operation returns data, but if there are a lot of read operations queued up then it might take 5000ms for the read operations to finish. This is definitely not real-time, but it is low-latency.
WEP is a very weak protocol. The scary thing is that some vendor WEP implementations are actually even _more_ weak than a complete and correct WEP implementation would be.
Avoid any new technology for security--not only does it not have a lot of analysis and peer review on paper, but vendors usually don't get the implementation right on the first try in silicon and code. Chances are if the spec has "theoretical weaknesses," the vendor's product will have "exploitable vulnerabilities."
I generally design such systems by re-using existing practices and technology wherever possible. So my wireless LAN is a bunch of AP's connected to an ethernet switch (or, if you have less than about 8 AP's in one site with a few 100mbit wired ports on each, you can usually just connect them all to each other). The wireless LAN is then connected to the hostile side of the existing corporate firewall--either the firewall connected to the Internet, or a nearly identical copy of it. The wireless LAN and anything connected to it is assumed to be as hostile as the public Internet.
For extra security, add an IDS box to monitor the network. The IDS box should do both passive listening (watching for non-VPN traffic) and active scanning (scan for open ports on all active IP's), and should be able to disconnect misconfigured hosts. Most AP's have some kind of web or SNMP interface these days that the IDS box can use, and most should support allowing or denying traffic based on MAC address of the wireless card.
The role of the IDS box here is to detect and shut down script kiddies and legitimate users with fatally misconfigured machines (e.g. the user or some program has tampered with the security policy or disabled the client's firewall). You probably want one of these even if you're doing 802.1x stuff, or even on Internet connections, since any machine connected to the protected LAN--from anywhere--that isn't sufficiently locked down creates a vulnerability for the entire LAN. The IDS doesn't give much protection against competent attackers, but it does let you know about the incompetent ones nicely.
Of course, the IDS box opens up a whole world of DoS attacks...and you'll need someone to monitor it...and if your VPN and firewalls are working, you don't need (or already have) IDS. So I consider it optional, and leave it up to my client to decide to use one or not.
On the client machines I use exactly the same VPN and firewall security software that I use for machines who attach to the LAN from the public Internet. It doesn't matter what VPN you use here. All the wireless I or my clients have deployed so far use different VPN products in their implementations. Since the same VPN is used for wireless and the existing external Internet access, the client doesn't have to retrain anyone or reconfigure or reinstall anything.
IMHO the public Internet is a much more dangerous place than a wireless network--with wireless, your attackers have to be within a certain physical distance, while on the Internet you can be attacked by anyone in the world.
There are three things that really annoy me about autoconf (and the autobook, for that matter):
The autobook examples of missing functions are trivial (meaning that the missing function is easily implemented in terms of non-missing ones--so easily, that any reasonable compiler would generate code identical to what would be generated if the package developer had written two sets of code with #ifdef HAVE_ macros). It is much easier for autoconf to simply implement strstr() in config.h if it detects that you only have index(), than it is to write, debug, and maintain one copy of every such function for every single project ever written. The code could easily fit within 'configure' itself.
It would be a good idea for the GNU autotools project to create a single.h file (or.h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc isn't really used in this way.
The first thing any./configure script should do is look for a newer version of autoconf on the installer's build system, and upgrade its config.guess/config.sub/configure files appropriately (of course with a suitable --without- or --disable- option to turn this off, in case the package maintainer's version of autoconf is less broken than the package installer's version):
checking for autoconf... ok
checking version of configure... 1.2.3
checking version of autoconf... 1.2.4
creating configure
restarting./configure
Autoconf, and libtool and automake, seem to be missing support for compiling with profiling, debugging, and optimization. If you thought building cross-platform shared libraries was a pain, try building a project with working profiling or debugging support on several different compilers. I would love to have a "--enable-profiling" flag for./configure that would automagically work consistently across platforms...
autoconf, like libtool and automake, really only solves part of the much larger problem of portability. In the limiting cases, there are only two ways to build a portable system: either use the lowest common denominator, or link to a runtime library that contains functions you need and that has been ported to every platform you care about. Things in between these extremes are really just the above rule applied to individual features--if you don't HAVE_OFF64_T, then you have to design your code for systems that don't HAVE_OFF64_T (note that simply allowing your code to bomb in implementation-defined ways when given any file bigger than 2 gigabytes is, in a technical sense, designing your code for non-HAVE_OFF64_T systems). On the other hand, if you don't HAVE_BASENAME, then you just supply your own and move on.
Once Linux achieves world domination, autoconf will be obsolete (well, except for choosing between multiple installed versions of packages, and the --prefix/--enable/--with override options).
It would be a good idea for the GNU autotools project to create a single.h file (or.h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc can't easily be used in this way at the moment.
if you have some experience in tech support, you can easily find another job doing tech support.
It may well take (salary$NK/$10K) weeks to find a better job, especially if you have no training or experience for it. Not many employers are willing to take a loss on you while you get up to speed, especially employers who are accustomed to hiring off-the-shelf, pre-trained labor.
However, it should be trivial to find an identical job, especially in call-center tech support, assuming that the area in which you live has sufficient economic mass to sustain more than one employer. If you can't find a job this morning, come back in the afternoon.
Sometimes location does help. Where I live, even McDonald's is resorting to desparate recruiting measures. Even so, 90% of the calls and emails I get from prospective employers are from diverse regions of the U.S. and Canada.
Half the time I don't even think the jobs they advertise exist.
Half? Even if 95% of the jobs advertised by recruiters didn't exist, the 10% remaining is quite sufficient for rapid re-employment. Frankly, any recruiter who calls without a job in hand is wasting their time--they will be soundly outcompeted by the ones who do.
In the specific case of artists represented by RIAA, the record company is the legal owner of the copyrighted music, so you (the freeloading consumer;-) pay the record company. The artist is not involved in this transaction, and in the U.S. probably has no rights of any kind other than what is explicitly provided to them by the record company.
In the case of artists who are independent of any record company...they usually have a legal corporation or sole proprietorship anyway just for tax purposes, even if the "record company" has no employees that are not also musicians or their accompanying roadies.
Cassettes have goshawful noise and reliability problems. The motion system is designed to be cheap to implement and good enough for recorded voice, and it's too slow for high fidelity; I doubt the designers of the first audio cassettes ever imagined that someone would do something as horrible as putting _music_ on them.
Cassettes are fiendishly expensive to produce, too: a CD or LP is just pressed (stamp, done), while any kind of cassette tape is recorded, serially (playing...playing...playing...(15 minutes later) playing...playing...done).
If you really doubt that cassettes are more expensive than CD's, count the number of pieces: a CD has maybe three (plastic, aluminum foil, plastic), while a cassette has dozens in a variety of different metals and plastics.
I can't imagine why cassettes are cheaper than CD's at music stores, unless the market is such that you just can't sell a cassette for any higher price, or the recording industry truly _is_ evil. A cassette costs nearly a buck, a CD costs ~10 cents.
DecNet is obsolete. Plain ol' ethernet bridging (not to be confused with routing) requires the ability to set arbitrary MAC source addresses on each outgoing packet. Various IPX-based failover and routing systems require this capability too. Also the Ethernet people don't always get their standards straight, requiring support for yet another header format.
I haven't actually seen a network card that doesn't support arbitrary MAC, but I suppose that some old 8-bit ISA cards may still exist--if you have such a beast, mount it on your wall and get a network card capable of at least a megabit of throughput after host bus overhead.
Note this change usually isn't permanent, i.e. we're not overwriting the NVRAM on the card or anything. The capability is simply due to the fact that the chip doesn't prepend the ethernet header for you, so the software has to fill in the second six bytes of each packet. Linux reads the MAC address from the card's ROM as a default, but you can override this with 'ifconfig', and for Linux bridging the source MAC address is set for each packet forwarded across the bridge.
I'm willing to bet that a lot of NIC chipset designers intend for their chips (or at least most of the die) to be useful inside switches as well as inside network cards. Why design two different devices when you can just design one and sell it twice?
The gas is plain old air. Most hard drives actually have free flow of air between the outside and inside, with very, _very_ tight filtering.
Without the breathing hole, the changes in gas pressure due to heat would cause the drive casing to warp, throwing the geometry of the drive all to hell. Gas is necessary inside the drive because the drive heads float on a cushion of moving air, which keeps them exactly the right distance away from the platters.
If you compromise the case, you can still recover most of the drive data using the "usual" data recovery methods, the lowest-tech of which is to simply power up the drive without a case in a relatively dust-free room. Most hard drives will actually work for a few minutes under such conditions, and even when they do fail, you only lose a megabyte or two per dust particle, and there's lots of megabytes in a 20-gig disk.
Slashdot Mirror
No, manufacturers hold one key to solving this: if they would print in bold letters on a bright red label on the outside of the box, "WARNING: THIS PRODUCT BROADCASTS YOUR NETWORK (INCLUDING PR0N SURFING) TO ANYONE WITHIN ONE QUARTER OF A MILE", it would help.
Actually the distribution is exponential...one person uploads N copies to the P2P network...then N people upload their copy to N others each...etc.
So assuming that everyone uploads to exactly one other person on their 56K modem, we have about 22 iterations (44 days at 56K, 700 MB per day) before 4 million people have both movies. That's still much more than a weekend.
More realistic numbers: the movies are actually about 350MB in size (total 700MB, or one day at 56K), everybody uploads to four others, and the network speed is 256kbits (64kbits/person). Now we have 4 million people served in a mere 11 iterations, each iteration taking a mere 6 hours--a little under three days for the whole thing.
Most people who have broadband have some kind of asymmetric arrangement, and the two movies are separate entities, which means we can assume that everyone who's downloading is talking to two people who are uploading, and they are transferring both movies at the same time. This cuts the iteration time down to three hours, which makes the whole thing fit nicely (if only theoretically) into a weekend.
Typical sizes for movies soon after theatrical release are 350-400 MB, in DivX format. This is for a crappy camcorder version. 700MB+ VCD movies don't arrive until some time later--it takes a little longer because the physical film has to 'disappear' for a few hours.
so 700 MB times 4 million = 2.6 petabytes, or 9000 people with cable modems using 30% of their bandwidth each for a month.
OK, a medium-sized CRT-based TV set consumes ~100 watts of power. Much of that power is radiated as heat and light, but a good chunk is radiated as a really powerful electromagnetic signal that can be converted back into an image for hundreds of yards, and parts of the signal (especially vsync) can be detected for *miles*. Simply put a trace signal on some channel and listen for anyone watching it. The equipment for full image recapture costs a few tens of thousands of dollars but it is well within the budget of a multi-million dollar cable company. A simple vsync detector is two orders of magnitude cheaper.
You can defeat this method by using an LCD display device, or by recording everything on cable and watching it at some other time (and frankly, I would do that in any case just to avoid commercials).
I've run ReiserFS against ext3 head-to-head (redundant servers, mirrored data, load-balanced services, hardware as identical as it gets) since 2.4.10 or so. For 8 years prior to that, I've run ext2 on hundreds of Linux boxes. Crashes, corruption, software bugs, memory defects, bad sectors, overheating RAM, viruses...I or my clients have seen it all.
When it works(*), reiserfs and ext3 are nearly identical in terms of performance and reliability, except for some corner cases with data appended to files close to an unclean shutdown (ext3 discards uncommitted data, while reiserfs (and ext2 for that matter) puts garbage at the end of the file). Of course, if you have a directory structure that obviously favours ReiserFS (flat namespace or small files), then reiserfs may be faster; however, for typical Windoze/Linux file service, the advantage or disadvantage of ReiserFS is negligible.
Now for the (*): Murphy works at your company. Things will always go wrong, be they due to human failure, hardware failure, or software failure. When ext3 goes wrong, you can apply e2fsck (a very fine although still somewhat imperfect automated recovery tool), debugfs (a very fine hand-reconstruct-your-filesystem-tool), some third-party data recovery tools (open-source and proprietary), and the filesystem structure is sufficiently straightforward that you can easily recover most lost data "by hand" if you can't get it back from any of those.
Of course backups are part of any good data recovery strategy; however, it often comes down to a choice between spending 20 days restoring data from tape, 36 hours waiting for reiserfsck, 54 hours waiting for rebuild-from-scratch from a mirror server, or six hours recovering 99% of it with ext2 recovery tools. The ability to crawl through the filesystem looking for data is as important as any other data recovery strategy.
ReiserFS has data recovery tools which--in their own documentation--say "these tools are only of beta quality." reiserfsck simply cannot recover from several common kinds of filesystem corruption. The data structure of a reiserfs tree is a balanced tree with very little predefined structure--unlike ext3, in reiserfs you can't just search all inodes to look for files that have disappeared from any directory. If a reiserfs interior tree node is lost, a few percent of your filesystem at random will become inaccessible--contrast with a damaged ext3 block, which at worst loses a few dozen files, or loses filenames but without affecting the contents of the files. A full-blown tree-reconstructing reiserfsck involves reading the entire filesystem volume (or at least the nominally occupied parts of it) more than once, and there is no guarantee it will be successful.
Another important distinction between reiserfsck and e2fsck is that e2fsck will leave you with a usable filesystem, even if the data within is corrupted--that is, you'll be able to store new data on the filesystem safely. reiserfsck will not leave you with a usable filesystem in common cases--you'll either have to live with inaccessible storage, or rebuild the filesystem from scratch.
My current recommendation to clients is to use reiserfs only for workloads where recoverability of data is not a requirement--e.g. filesystems for squid caches, or mirrored servers, where it is acceptable to respond to filesystem corruption by starting over from mkreiserfs. In other cases, where e2fsck after a reboot is unacceptable use ext3, otherwise use ext2. Other filesystems are too new or too slow to care about.
Frankly, the only currently available, mature, robust filesystem with proper, well-supported tools on Linux is ext2--fsck's and all. Everything else is just a tool for discovering bugs the hard way.
These patents, if granted, will become the property of a legal person (corporation). This is VERY dangerous. The danger arises when the person might lose control over the patents.
It would seem to me that all a large company would have to do to get unlimited access to these patents is to start suing RedHat (it doesn't matter what for, and it doesn't have to be related to patents at all, as long as the legal costs of defense are mandatory and large) until Red Hat runs out of money, then show up when Red Hat's assets are sold at bankruptcy auction and walk away with a government-regulated monopoly on some useful pieces of free software.
This would result in the unfortunate situation that a critical component of certain free software might be held by an entity that refuses to license it on any but the most draconian terms.
Red Hat is (comparatively) well-funded for a Linux vendor. Smaller corporations shouldn't even attempt to play patent games, because the only two possible outcomes are 1) be ignored, or 2) lose everything.
Oh! Oh! Oh! Can we send Valenti into low Earth orbit without all the bulky space suits, oxygen supply, and stuff? Think of the savings in launch fuel costs!
I have done a security audit for a company that isn't Microsoft, but wants to be (don't ask, it's really sad). I'd like to say that I had help, but I didn't. Kids, don't try this kind of software project management at home.
/usr/bin matched patterns that suggested vulnerability, but fewer than 10% of the programs actually had exploitable vulnerabilities upon closer inspection. Most of the vulnerabilities were /tmp file-creation/symlink attacks, and many of the holes required the attacker to have very much control over the victims' activities to exploit.
/tmp-style exploits and buffer overruns, even when it is provably not necessary for security.
The thing about commercial software development (open-source or otherwise) is that the population of developers is small, and their schedule does not allow them to develop their coding style very much. As a result, you can usually recognize who wrote which code after you've read enough of it, and once you can do that, you can predict the quality of their future code based on past code.
The thing about security bugs in code that has NEVER been audited before is that most of them (by number) are the same basic stupid mistakes repeated over and over again.
Exploiting this to its full potential, you can find security holes with 'find' and 'grep'. In my case, about 250 security holes per hour (20 seconds of computer time, 3580 seconds of looking at the code in question and eliminating cases where calling or enclosing code prevents exploitation of dangerous code) in 275 KSLOC during the first day of auditing. This rate drops off to about 120 "hits" per search with maybe a dozen false positives (interestingly enough the false-positive rate always hovered around 10%), for a total of just over 1000 security holes in a single week.
After I made that pass, where I might be finding and even fixing multiple vulnerabilities in a single *minute*, I then look at who wrote the code I am fixing, who mentored them, who they mentored, etc. Basically I construct a picture from the corporate organization, the revision history, and the code, to find out who the bad coders are--then I audit everything they ever touched. This finds bugs of all kinds, but not all of them are security-related. There are still dozens of security bugs found per day using this search strategy.
Another search tactic is to do global source code searches for the variable names in functions I am fixing, and for the syntactic structures (i.e. everything around the variable names). This finds an amazing amount of plagiarization, as well as code examples that might have originated from corporate training or "learn language_X in N days" books and which were cut + pasted without any further thought about issues like checking for error returns or invalid inputs.
Note that the vast majority of the bugs found were the Unix equivalent of taking a string from an untrusted entity, blindly sprintf'ing it into an automatic array variable, and feeding the result to system() -- three different security holes in as many lines of code. This is probably also true of Microsoft code--thousands upon thousands of instances of a handful of problems, over and over again.
Simple bugs require only a few seconds to fix, especially if you are looking at repeated errors made by the same coder, and you've already worked out a general solution. Other bugs require more time, but very few bugs require more than a few hours to fix--instances where a redesign is required are very rare, and often this kind of problem is discovered by other means (e.g. by looking specifically for network servers or programs that run setuid, instead of searching for dangerous code fragments). The average time required is MUCH less than 8 minutes per line of code--it's actually closer to 8 minutes per bug, and 4 bugs per KSLOC.
Assume an average bug rate of one bug per 500 lines, and an average review rate of 8 minutes per line, I'd have 4000 minutes per bug for analysis and repair. That is plenty of time to get rid of 99% of the bugs--I spent less than 4000 minutes on my entire audit, and given 4000 minutes per bug I could learn a new programming language for each one!
This kind of audit certainly does not fix all problems--the security holes that were found after the release of the code I audited attest to that. Audits like this don't produce perfect results, only better ones--half a dozen exploitable vulnerabilities are much better than a thousand.
This is what we can expect from Microsoft: fewer stupid vulnerabilities in the short term, fewer bad design decisions in the long term, with no noticeable impact on the more sophisticated attacks in any amount of time.
Incidentally, I also did an audit of a Linux distribution using more or less the same technique. I found that about 90% of the programs in
Some time after I did the Linux audit, Linux distribution vendors started taking security seriously. Now when I audit Linux programs I'm pleasantly surprised to discover that they are already hardened against
Thanks to sites like this one, I can sharpen my legal threatening skills without expensive legal training or hiring expensive lawyers.
In my country we get 340+ TV channels (minimum) from a number of competing cable & satellite providers.
_Not one_ of these channels is the Sci-Fi Channel.
Damn the US!
Advocates of auto-detection instead of manual configuration I'll deal with right now: Applications in certain problem domains require explicit human-supplied configuration data. This is unavoidable in any application that has to implement some choice of policy, especially security policy. There are some things you can't ever autodetect, so if you can't configure the application, then you need many different applications, each hard-wired for one possible desirable configuration. Certainly a lot of things that should be auto-detected are not, but auto-detection will not eliminate the configuration problem.
Windows and Mac are platforms controlled by a single vendor. That vendor has a _lot_ of influence over how applications are designed for that platform. When the vendor designs and implements the platform, the vendor will (intentionally or otherwise) reward applications with an architecture consistent with the vendor's design, and penalize those that don't. Applications tend to comply with the vendor architecture because the cost of non-compliance is greater than the cost of compliance.
Unix is not a platform controlled by a single vendor. Heck, it's not even a platform; it's a bunch of little standards that were chosen arbitrarily and stitched together. Linux, FreeBSD, SysV, BSD, Solaris, QNX, HP/UX, etc. are not Unix platforms--they are platforms compatible with Unix, implementing parts of the SUS, ANSI, and POSIX standards, with varying degrees of completeness and success. As such, there is no reward for making an application's architecture consistent with the OS vendor's design; contrariwise, there is a compelling reward for an OS vendor to make an OS architecture consistent with a desirable class of application.
The difference is critical for understanding the configuration file nightmares of both kinds of platform. Windows has a really awful configuration mechanism that nobody would ever use if they weren't compelled to; however, certain parts of Windows are only conveniently accessible via this configuration file format, easy (if not reliable) methods to access the format are provided to all developers and available on all end-user machines, and the configuration schema does not define a lot of policy to get in the way of extensions (need new schema? Add a new DLL!). The Mac has a different architecture and mechanism with the same consequences.
On the other hand, applications that run on Unix are, in whole or in part, designed for "other" systems. Applications that were designed and written exclusively on Unix-like platform X eventually get ported to some other Unix-like platform Y--those that don't tend to be eventually replaced by similar applications that do. When this happens, the resulting application is an alien on both platforms. The application must find everything it needs on each target platform, or it must bring with it those things that are missing from some target platforms. This means that the application will have translation or interpretation layers (all C apps have at least one translation layer in the C compiler) and replacements for missing functionality in the target platform.
Now for the delusions. New code written in a language with link-level compatibility with a free, small, fast, easy to use in code, portable, robust configuration mechanism library will have no problems. Note that the status quo is already as free, small, fast, easy to use in code, portable, and robust as it needs to be for applications that already use it, so alternatives which are not all of these do not merit discussion.
However, there are constraints imposed on this hypothetical library by legacy code:
- It would have to be already installed or available on all Unix-like systems with bindings to all Unix-like languages,
which rules out nearly everything invented after 1978. Otherwise, every application (and language!) must bring either a copy
of the library or their own code. Strangely enough, "open file," "read text line," and "lexically analyze this string" primitives
are implemented in nearly all Unix-like languages, and interactive text file editors are shipped on nearly all Unix-like systems...
- It would have to be as small and fast as fgets+scanf, or a lex+yacc parser, otherwise it will hurt performance or have
a large footprint, and people who care about performance or size won't use it. XML can't do this unless you drop the i18n and
character entity and encoding support--at which point it's not really XML any more.
- It will have to use small ASCII text files for persistent storage, otherwise you have to implement and force everyone
to use either your own editing mechanism (aka "a control panel DLL"), or you implement and force everyone
to use replacements for Unix filesystem-crawling tools which allow you to selectively access the data (aka "the registry and
regedit", or "replacements for cvs, vi, find and grep")--both of which violate the "once and only once" rule since these
facilities exist already in Unix and they are used for this purpose.
- It will have to be used directly by the actual applications--otherwise you violate the "once and only once" rule
by having either two configuration files and two applications (the real application, and a configuration application), or two
configuration file handling mechanisms in one application (for old-style and new-style config files).
It might be possible, given overwhelming demand, to convince maintainers of significant mature legacy code to adopt the new configuration mechanism, if the XML-based mechanism is more widely ported and better debugged than their own configuration-management code. Good luck, and be prepared to do the work yourself many, many times over until you either change their minds, or they leave the project and you're stuck maintaining the code by default.Note that other standardization initiatives, like FHS or the LSB, involve relatively superficial changes which application maintainers were probably willing to make anyway. The FHS and LSB ask application maintainers to change the parameters to a few system calls without affecting the architecture of any part of the application or the semantics of its operation. For example, the application may open()s a file, but after the FHS is implemented that file has a different name. Both names are constant strings, the file is still opened for reading, and it still has the same contents with the same syntax and semantics. A one-line change and a recompile brings the application into compliance, and in an emergency, a symlink will make the application work.
Other initiatives, such as DNS and PAM, are usually facilities that are not intrinsic to applications. Host name resolution or user access verification involve resources shared by many applications, and there is a real technical penalty for non-compliance.
Changing the way applications handle configuration is a large architectural change--you're asking people to replace open(), read(), close(), and some code which is intrinsic to the application with new functions that have different semantics, and may even have to be called at different times. Expect resistance.
The only hope of this ever happening in real life is for a Linux distributor to decide to implement it, and contribute the work to achieve it. Said vendor will have to hack and slash their way through hundreds if not thousands of packages to bring them into compliance. Once all of that is done, all the upstream package maintainers will have to integrate the changes--or all the other Linux vendors will have to repeat the hack-and-slash job.
No, it's $http_proxy. Yeesh.
It seems you're doing something wrong...where I work, the only access to the outside world is via the proxy; changing proxy settings to other values will result in loss of Internet access because values other than the ones prescribed by the company don't work.
Internal relaying is irrelevant because sooner or later all relays must go through the One True proxy to outside. PB doesn't really change that situation.
PB does allow an internal machine to co-operate with an external machine to make content more difficult to automatically classify (e.g. by disguising the URL so a URL filter won't work, or encrypting or transcoding the data so a content filter won't work). This is nothing new; there have been public web mediator sites for working around content filtering restrictions since probably a few hours after the first content filter was deployed, and PB is just another one. Maybe PB makes it easier to find many new open relays. Whee.
The only way to have secure content filtering is to maintain a white-list of sites, lock down all those sites plus the DNS and low-level communications paths between them and your content-filtering proxy, and deny all other traffic. This works but you need a content control officer to add each new approved site, and the security of the entire arrangement is equal to the security of the easiest site to crack. It does work well for things like promotional kiosks in stores, where you only want users to access your own web site.
Any other arrangement, even one that analyzes content, just leads to an arms race between deny rules, open proxies, and co-operative external mediators. IMHO this whole thing is a waste of time except for fixing very short-term problems (e.g. someone idiot starts 500 simultaneous mp3 downloads, so you block that site just long enough to apply a cluebat to the user).
It's usually a lot more effective to have people agree to a usage policy, then log traffic and discipline and/or fire people after the fact. You can kill off anything PB-like with a generic "no traffic we don't approve of or can't analyze" prohibition combined with logging.
3) Toolkits should be double-buffering everything, using client-side layout code (rather than X window objects), and holding all drawing until input events have been handled.
A lot of X toolkits are very dumb; they are little more than event loops wrapped around libX11 and maybe libXt. Many of the less-heavily-optimized toolkits don't bother collapsing events, or they make it difficult for applications to use such optimizations. Some toolkits leave redraw of non-widget objects entirely to the application, and most application authors are not going to bother writing proper minimal-refresh code, especially if the objects are simple enough that the delay for a full redraw on every expose event is tolerable.
In the worst cases (i.e. most of them, it seems), applications redraw _everything_ if _any_ part of their visible area is exposed, and the only optimization done is window clipping by the X server.
This is actually a problem in Windoze too, if an application is written the same way. Big/complex Windoze apps assign teams of people to fix their refresh bottlenecks, or they render everything double-buffered and do screen updates by bitblitting, or (ugh) they have a high-priority thread that just does screen updates while the low-priority threads do all the actual work, so the application _looks_ fast, when in fact it is slow.
Take a look at the implementation of Gtk or Tk canvas objects to see what hoops you have to jump through to get smooth updates of complex graphic objects. Also take a look at how fast you can resize windows owned by these objects. Then look at applications designed for lesser toolkits and see all the duplication of effort this leads to.
Low-latency is just that--the kernel tries to keep the latencies lower than whatever you're comparing it to. The same kernel A may be low-latency when compared to kernel B, but A may be high-latency when compared to kernel C.
Realtime is a boolean attribute: either you're realtime, or you're not. A realtime kernel specifies the maximum and maybe the minimum latency for various requests.
These two attributes are orthogonal: a kernel may be low-latency but not real-time, vice-versa, both, or neither.
For example, a real-time kernel may guarantee that you'll get to do one disk read per second (as long as the disk hasn't completely failed, the kernel hasn't crashed, etc). It might make the guarantee stick by ALLOWING only one disk read per second, even if the disk is idle 99% of the time, and your disk is doing absolutely nothing for 999.9ms between consecutive read requests. Not low-latency, but certainly real-time.
A low-latency kernel may allow read requests to complete as quickly as possible, but it may not guarantee a maximum time for read requests to complete. So your application will be able to start executing 100ns after a read operation returns data, but if there are a lot of read operations queued up then it might take 5000ms for the read operations to finish. This is definitely not real-time, but it is low-latency.
WEP is a very weak protocol. The scary thing is that some vendor WEP implementations are actually even _more_ weak than a complete and correct WEP implementation would be.
Avoid any new technology for security--not only does it not have a lot of analysis and peer review on paper, but vendors usually don't get the implementation right on the first try in silicon and code. Chances are if the spec has "theoretical weaknesses," the vendor's product will have "exploitable vulnerabilities."
I generally design such systems by re-using existing practices and technology wherever possible. So my wireless LAN is a bunch of AP's connected to an ethernet switch (or, if you have less than about 8 AP's in one site with a few 100mbit wired ports on each, you can usually just connect them all to each other). The wireless LAN is then connected to the hostile side of the existing corporate firewall--either the firewall connected to the Internet, or a nearly identical copy of it. The wireless LAN and anything connected to it is assumed to be as hostile as the public Internet.
For extra security, add an IDS box to monitor the network. The IDS box should do both passive listening (watching for non-VPN traffic) and active scanning (scan for open ports on all active IP's), and should be able to disconnect misconfigured hosts. Most AP's have some kind of web or SNMP interface these days that the IDS box can use, and most should support allowing or denying traffic based on MAC address of the wireless card.
The role of the IDS box here is to detect and shut down script kiddies and legitimate users with fatally misconfigured machines (e.g. the user or some program has tampered with the security policy or disabled the client's firewall). You probably want one of these even if you're doing 802.1x stuff, or even on Internet connections, since any machine connected to the protected LAN--from anywhere--that isn't sufficiently locked down creates a vulnerability for the entire LAN. The IDS doesn't give much protection against competent attackers, but it does let you know about the incompetent ones nicely.
Of course, the IDS box opens up a whole world of DoS attacks...and you'll need someone to monitor it...and if your VPN and firewalls are working, you don't need (or already have) IDS. So I consider it optional, and leave it up to my client to decide to use one or not.
On the client machines I use exactly the same VPN and firewall security software that I use for machines who attach to the LAN from the public Internet. It doesn't matter what VPN you use here. All the wireless I or my clients have deployed so far use different VPN products in their implementations. Since the same VPN is used for wireless and the existing external Internet access, the client doesn't have to retrain anyone or reconfigure or reinstall anything.
IMHO the public Internet is a much more dangerous place than a wireless network--with wireless, your attackers have to be within a certain physical distance, while on the Internet you can be attacked by anyone in the world.
- The autobook examples of missing functions are trivial (meaning that the missing function is easily implemented in terms of non-missing ones--so easily, that any reasonable compiler would generate code identical to what would be generated if the package developer had written two sets of code with #ifdef HAVE_ macros). It is much easier for autoconf to simply implement strstr() in config.h if it detects that you only have index(), than it is to write, debug, and maintain one copy of every such function for every single project ever written. The code could easily fit within 'configure' itself.
- The first thing any
./configure script should do is look for a newer version of autoconf on the installer's build system, and upgrade its config.guess/config.sub/configure files appropriately (of course with a suitable --without- or --disable- option to turn this off, in case the package maintainer's version of autoconf is less broken than the package installer's version):
- Autoconf, and libtool and automake, seem to be missing support for compiling with profiling, debugging, and optimization. If you thought building cross-platform shared libraries was a pain, try building a project with working profiling or debugging support on several different compilers. I would love to have a "--enable-profiling" flag for
./configure that would automagically work consistently across platforms...
autoconf, like libtool and automake, really only solves part of the much larger problem of portability. In the limiting cases, there are only two ways to build a portable system: either use the lowest common denominator, or link to a runtime library that contains functions you need and that has been ported to every platform you care about. Things in between these extremes are really just the above rule applied to individual features--if you don't HAVE_OFF64_T, then you have to design your code for systems that don't HAVE_OFF64_T (note that simply allowing your code to bomb in implementation-defined ways when given any file bigger than 2 gigabytes is, in a technical sense, designing your code for non-HAVE_OFF64_T systems). On the other hand, if you don't HAVE_BASENAME, then you just supply your own and move on.It would be a good idea for the GNU autotools project to create a single .h file (or .h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc isn't really used in this way.
checking for autoconf... ok ./configure
checking version of configure... 1.2.3
checking version of autoconf... 1.2.4
creating configure
restarting
Once Linux achieves world domination, autoconf will be obsolete (well, except for choosing between multiple installed versions of packages, and the --prefix/--enable/--with override options).
It would be a good idea for the GNU autotools project to create a single .h file (or .h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc can't easily be used in this way at the moment.
Even if 95% of the jobs advertised by recruiters didn't exist, the 10% remaining...
;-)
Drat, too much blood in the caffeine stream...
However, it should be trivial to find an identical job, especially in call-center tech support, assuming that the area in which you live has sufficient economic mass to sustain more than one employer. If you can't find a job this morning, come back in the afternoon.
Sometimes location does help. Where I live, even McDonald's is resorting to desparate recruiting measures. Even so, 90% of the calls and emails I get from prospective employers are from diverse regions of the U.S. and Canada.
Half? Even if 95% of the jobs advertised by recruiters didn't exist, the 10% remaining is quite sufficient for rapid re-employment. Frankly, any recruiter who calls without a job in hand is wasting their time--they will be soundly outcompeted by the ones who do.In the specific case of artists represented by RIAA, the record company is the legal owner of the copyrighted music, so you (the freeloading consumer ;-) pay the record company. The artist is not involved in this transaction, and in the U.S. probably has no rights of any kind other than what is explicitly provided to them by the record company.
In the case of artists who are independent of any record company...they usually have a legal corporation or sole proprietorship anyway just for tax purposes, even if the "record company" has no employees that are not also musicians or their accompanying roadies.
Cassettes have goshawful noise and reliability problems. The motion system is designed to be cheap to implement and good enough for recorded voice, and it's too slow for high fidelity; I doubt the designers of the first audio cassettes ever imagined that someone would do something as horrible as putting _music_ on them.
Cassettes are fiendishly expensive to produce, too: a CD or LP is just pressed (stamp, done), while any kind of cassette tape is recorded, serially (playing...playing...playing...(15 minutes later) playing...playing...done).
If you really doubt that cassettes are more expensive than CD's, count the number of pieces: a CD has maybe three (plastic, aluminum foil, plastic), while a cassette has dozens in a variety of different metals and plastics.
I can't imagine why cassettes are cheaper than CD's at music stores, unless the market is such that you just can't sell a cassette for any higher price, or the recording industry truly _is_ evil. A cassette costs nearly a buck, a CD costs ~10 cents.
DecNet is obsolete. Plain ol' ethernet bridging (not to be confused with routing) requires the ability to set arbitrary MAC source addresses on each outgoing packet. Various IPX-based failover and routing systems require this capability too. Also the Ethernet people don't always get their standards straight, requiring support for yet another header format.
I haven't actually seen a network card that doesn't support arbitrary MAC, but I suppose that some old 8-bit ISA cards may still exist--if you have such a beast, mount it on your wall and get a network card capable of at least a megabit of throughput after host bus overhead.
Note this change usually isn't permanent, i.e. we're not overwriting the NVRAM on the card or anything. The capability is simply due to the fact that the chip doesn't prepend the ethernet header for you, so the software has to fill in the second six bytes of each packet. Linux reads the MAC address from the card's ROM as a default, but you can override this with 'ifconfig', and for Linux bridging the source MAC address is set for each packet forwarded across the bridge.
I'm willing to bet that a lot of NIC chipset designers intend for their chips (or at least most of the die) to be useful inside switches as well as inside network cards. Why design two different devices when you can just design one and sell it twice?
AFAIK, since they own the copyright in their own music, they can legally
make whatever copies of it they like.
Whether they can legally use your equipment to do so is a separate
question.
The gas is plain old air. Most hard drives actually have free flow of
air between the outside and inside, with very, _very_ tight filtering.
Without the breathing hole, the changes in gas pressure due to heat would
cause the drive casing to warp, throwing the geometry of the drive all
to hell. Gas is necessary inside the drive because the drive heads float
on a cushion of moving air, which keeps them exactly the right distance
away from the platters.
If you compromise the case, you can still recover most of the drive data
using the "usual" data recovery methods, the lowest-tech of which is to
simply power up the drive without a case in a relatively dust-free room.
Most hard drives will actually work for a few minutes under such
conditions, and even when they do fail, you only lose a megabyte or two
per dust particle, and there's lots of megabytes in a 20-gig disk.