Well, yeah, that's the rub. I want to use it to pull uncompressed digital audio, and eventually MPEG2 video from over the home LAN, to drive (first) the stereo, and the high-res TV or monitor, respectively.
Thus, a fan is verboten.
I realize that hardware DVD decoding might require that level of active cooling, but surely a fanless solution exists that will at least do X and the digital audio stuff, leaving the video for later.
Even so, proper heat pipe technology should make it possible to use passive convection cooling. Look at the Mac Cube, for an example (and it doesn't even need a heat pipe).
Finally, I am willing to live with an outboard "brick" style power supply, if that helps remove the fan requirement.
Minnisota isn't a city... and (< Ob. insult> ) more importantly, there is nothing of value there...
Seriously, how do they deal with snow there? In Montreal (where I lived for 36 some odd years), the general rule is, big snow removal gear, running since early in the storm, and often. The downside is 2-3 feet high by 4-6 feet long by the width of the driveway of hard packed snow to clear (and a 10 foot high pile at the end of the front yard).
As a Canadian living and working in the U.S. (legally), I find this incredibly funny. I can't resist pointing out a few things though,
<Ob. Canadian "eh"> eh?
1. Yes, American beer is like sex in a canoe (fsking close to water), but I've never seen an American drink that swill -- the decent imported stuff is cheaper than soft drinks here.
2. Texas wild pigs vs. Moose: Imagine a small import car. Imagine it three times it's usual size, but with the same weight. Imagine it mad at you. You got moose. (They're essentially docile, and blind, but can get pretty mean if pissed off).
3. Canadians are world experts at telecom. They could probably coordinate a multi-city syncronized surprise attack from above. How much of telecom experts are Canadians? Canada is so big, with parts so remote, we shot up satelites with the sole purpose of delivering television to people... in the 1960s.
4. Failing a military-style assault, Canadians, well French Canadians from Quebec, could resort to a secret weapon: Poutine. It's got enough artery-clogging stuff to kill even the most insensitized couch potato. Consider it culinary warfare. Quebec soft drinks (to wash it down) contain triple the usual dose of sugar and so rot one's teeth to the point of rendering them ineffective -- the yanks couldn't even bite the invaders (and lest anyone think that Americans won't eat garbage, remember that they invented McDonalds, KFC, and, shudder, Taco Bell, complete with talking dog).
5. Canadians would attack in winter. From my experience, American cities and snow don't mix, becoming crippled with a 12 inch snowfall. Canadian cities get this about every 3-4 weeks in the winter. Nothing stops. Imaging a snowblower with a 100 inch wide and 36 inch tall maw, blowing snow 30 feet into the back of a truck (or your front yard). Imagine a vehicle big and strong enough to push the thing. Canadians know how to deal with snow. Americans don't even know what "snow tires" are. Yup, Canadians would attack in winter.
6. Celine Dion, Anne Murray, and Rita McNeal. What, you thought they were singers? Canadians think of them as "acoustic soldiers".
Picture this: you've sold thousands of remote units distributed all over the country that are tied into a communication network (er. TCP/IP/PPP over an X.25 SVC at a relatively low bit rate). Everything works until you start to download large amounts of data (i.e. a new software load). How do you fix it?
Answer: identify the combination of client and server TCP bugs that conspire to break long sessions; download a small code snippet that patches away enough of the bugs in place, so you can download a completely fixed app and new TCP/IP stack.
Ok, so it isn't thousands of miles UP, but it's thousands of times dozens of miles SIDEWAYS.
In fact, I'm considering packaging infozip (which is free, and needed to unzip encrypted proprietary code) as source in an RPM that gets compiled at install time for a different reason: U.S. export controls on open source strong crypto.
You can freely export open source strong crypto (which is probably already outside the U.S., so restrictions are pointless), as long as you do it in source form, and send a copy to the spooks.
Really, though, to what limits are you willing to go?
Would you be willing to kill anyone who tried to stop you from reading this book allowed? Because that's what it might take, when they come after you. If you truly believe (at least in the U.S.A.) that you have a constitutional right to something (and this might not qualify, but serves as a useful example, and damn well should qualify), surely you can legally use deadly force in defending that right, commensurate with the efforts of those who would seek to deny you it.
So, I ask you, would you be willing to kill those who would seek to prevent you from reading to your children?
If not, then the battle is lost before it is begun, for all that it will take is someone using any force to stop you.
It was great when 20 Mb was a lot of data, but now, it's rather obsolete.
Alpha Micro is one of those orphan companies that just keeps going, and going, and going. They started life in 1976 with a 16 bit bit-slice CPU running on a modified S-100 (i.e. Altair) bus (these mods later became the IEEE 696 16-bit S-100 bus standard, IIRC). Came with an assembler, bytecode-compiled BASIC, and a multi-tasking, multi-user O/S (AMOS).
Yes, that was in 1976 -- pre IBM PC, pre Apple, pre CP/M, and espescially pre-Microsoft.
Sadly, the world went a different way (CP/M, DOS, Windows, and Unix (which was already around)), than did Alpha Micro. Still, they manage to stick around.
I had written LOTS of assembler code for that machine, including the SPY program, which allowed one terminal to shadow another one, even if they ran at different baud rates and used different screen control codes.
Ah, the memories.
Re:The problem is in the dependency database
on
An RPM Port Of APT
·
· Score: 1
I'll pass that on... the powers that be here think that "building RPMs is too hard for developers". I don't buy that crock, espescially when they are developing for Red Hat based systems.
I've already provided a copy of Maximum RPM as a reference (dated as it is), and sample.spec files, but still face resistance.
Re:The problem is in the dependency database
on
An RPM Port Of APT
·
· Score: 1
Heh. I've started to push the notion that the work product of our developers (who produce code for embedded RH 6.2 systems) should be an RPM and not merely "source code checked in to the source code control system" (unless that includes a.spec file).
A unifying front-end to rpm and deb package formats can only be a good thing. However, there are some other issues, that I have recently become painfully aware of in the course of packaging for the development and execution environments for a product I'm helping develop.
First: Scalability. I want to be able to treat a set of packages as a single unit. It becomes unmanagable to set up a development environment for a particular product by requiring the installation of a dozen packages on top of a "stock" O/S installation. I've written a small Perl script to help me do this (since a script inside of an RPM spec file can't call RPM recursively due to its database lock). It supports notions of package set inheritence as well (so the foo development environment can include the generic development environment).
Second: source access. In a commercial environment, we can't go downloading and building packages from an external site. We need to ensure package consistency, and so cache all packages in our source code control system. It would be nice for a packaging system to allow specifications of multiple alternate source locations, and insisting on a particular one. It would be nicer if the package management system supported local or nfs path specs to such source. (RPM looks like it doesn't).
Third: Source Format. When building packages that we have not modified a tar or bzip source code archive is fine. However, for our own packages, we'd like to build from non-archived sourc code directories trees within the source code control system, since that's how our source code is managed.
Fourth: Source code references. When we include 3rd party RPMS of GPL code on a product distribution CD, we of course, have to also provide the corresponding source code on a companion source CD. It would be nice to match binary RPMS to source counterparts, and audit the match (so we don't have to build all such RPMS from source).
In general, I avoid NDAs where I sign away rights to code I develop on my own time unless it clearly relates to something I'm doing for hire.
But this goes further than that. It explicitly codifies what such things are, protecting the coder. Furthermore, there's a whole 'nother aspect to this: the company that recycles Free (as in FSF) anf Open Source software in the products it produces.
Where I work we aggregate a great deal of code with Free software (specifically, major portions pf Red Hat [GNU/]Linux). Sometimes we extend GPL code (and will have to release our changes when we ship product). We've actually had RMS here to address our developers on the GPL and sensitize them to the fact that we take complience with it seriously. But, once you start using the fruits of the open and free sofware communuties, even if you ensure GPL complience, there's somewhat of a moral pressure to give something back, i.e. release your own original code as GPL, or otherwise open.
With this in mind, I've been striving for us to take the position that code we develop is either strategic to a product or product line, or not. If not, I argue that it should be GPL for two reasons: First, it helps make us good free and open software community corporate citizens. Second, it often represents overhead code that doesn't generate direct revenue through licensing, but requires support nevertheless. A community of people who can also use and extend it, is therefore a benefit. Sometimes we produce code that is stillborn: it would have to be released under the GPL if we distributed binaries, but we have decided not to make it part of a product. Why let such code rot? Why not give it away, in the hopes it might find a home?
Often, other than legal GPL complience, the effort to do these things is not justified by the company. an appropriate OSDA agreement would empower employees who feel this way, to release such code themselves, without fear of reprisials. That can only be a good thing.
The reason that yelling fire in a crowded theater when there is no fire is because there is no time for rational reflection, and not because somehow the right to free speech is protected.
I used to play when I was younger. My father taught me the game, and I honed my skils in high school (some of my opponents were very good: one of them was the provincial champ for several years running). I got half-decent at it, but never exceptional.
Recent I had the pleasure of losing (as funny as that might sound) to a fellow I met in an "Einstein's Bagels": I had seen him play another once, and play several games out of an openings book, and he was willing to engage me in a game. Note: I hadn't played seriously in at least 20 years.
While I lost (Well, I resigned. The one redeeming fact was that I realized it was over earlier than most), it was a lot of fun.
Disclaimer: I am not a lawyer, not even an immigration attorney. Consult your own attorney for legal advice.
Your friend's exprience may suggests that her employer may be breaking the law.
I am a 39 year old Canadian citizen in the U.S. on an H1-B visa as well, and my employer has obtained a labour certification for a permanent position offered to me. More on that later. I arrived in the U.S. on a Nafta TN-1 visa on November 4, 1997, renewed once, and obtained an H1-B subsequent to my employer's petition in December of 1999.
Now, the TN-1, or NAFTA visa is open only to Canadians (with a TN-2 equivalent for Mexicans), for one year only, for a temporary position. It may be renewed indefinately, but your intent to stay in the U.S. is presumed to be temporary and that may be questioned if you have "too many" renewals. You need a degree from a recognized university or equivalent professional experience, and the job must be in one of several catagories. For example, systems analyst is a recignized
profession, but programmer isn't. Basically, you show up at a U.S. port of entry with an offer letter from the U.S. employer that lists the job correctly, proof of your degree or experience, and proof of Canadian citizenship. There's a processing fee, US$50 when I went. You can renew either by mail or at a POE (port of entry). The salary is supposed to be commensurate with normal wages paid to Americans, but is not checked uness a complaint against the company is filed. You must support all U.S. social programs via your taxes, but may not benefit from them. You CAN benefit from public schools (for your kids) because they are generally funded from city property taxes and not federally. Now according to the NAFTA legislation, the degree doesn't have to match the job, but the INS officer has a great deal of discretion to deny you entry if it doesn't match. Tough. The presumption is that anyone entering the U.S. is doing so illegally, and you have to prove otherwise. Changing jobs isn't too bad: you have to get another TN-1 for the new employer, but I think you have to go to the border to do it. It's a bit tricky because you have to start work for the new employer shortly after entering the U.S. on the new TN-1. There is no limit on NAFTA visas, and the process can go quickly. Of course, you risk ending up on the wrong side of the border if something goes wrong.
The H1 visa is different. It's good for three years, renewable once. In order to be in H1 status again, you have leave the U.S. for a year. You CAN revert to a TN-1 if the six years are up, but the whole "temporary intent" issue may be questioned. AFAIK, lying to an immigration officer is a felony and may be grounds to be barred from entry to the U.S. for a ong time (I'm not sure how long).
H1 visas are availible for anyone, not just Canadians and Mexicans, like the NAFTA visas. There is an annual cap. To get one, the sponsering employer files an LCA (Labor Certification Attestment), which is a testiment that the foriegner will be paid the going wage in the industry, and isn't being hired to replace Americans locked-out or on strike. There may be restrictions regarding recent layoffs. So, if a company hires someone on an H1, and underpays them, a complaint to the INS is in order. Basically, such an employee can't be treated any worse than an American employee.
Now, I'll be the first to admit that there can be a difference between law and practice. I don't like to see H1 workers treated as indentured slaves and particularly underpaid, because it strengthens arguments by American workers that they take their jobs away. Of course, such arguments should be levelled at the employers violating the law.
A game often played with H1 tech workers is that, instead of being underpaid, they're overworked, forced to work overtime without pay. Since their presence in the U.S. depends on their employment, they can feel trapped. But, again, tech workers in general can be so treated, espescially in States that permit "exempt" employees to not be paid overtime. Still, it is difficult for the H1 worker to leave poor working conditions.
While it is possible for an H1 visa to be transferred to another employer, the actual process is time-consuming: the new employer has to get an LCA approved, file an petition to hire the H1 worker, and then the worker with the existing H1 visa can begin work for the new employer. A year ago, in Illinois, the process took four months. The current employer need NOT find out until the employee actually starts to work for the new employer, but you can only work for one employer at a time. If the current employer finds out vbefore the process is complete, the results may be disasterous: you have 10 days to leave the
country.
Now, a bill currently in the process of moving to become law makes some changes to make it easier for H1 workers to migrate to better jobs, limiting opportunities for indentured serviture: you only have to have applied to begin the transfer process in order to start working for a new employer (but, if that is not approved, you have no safety net). In addition, people nearing the end of their H1 visa 6 year limit can get annual extentions while they have green card AOS (adjustment of status) pending. Contrary to at least one post here, you can apply for a Green Card while on an H1 visa (and even a NAFTA visa, though that's more iffy -- more later).
This used to be a big problem. Getting a green card (i.e. employment based immigrant visa), involves three steps, LC (labor certification), I140 immigrant petition, and AOS (adjustment of status), or CPIV (consular processing). This can take from one year to more than six years (hence the problem with H1 visas expiring).
The first step, LC, involves the employer applying for labor certification to hire a foriegner for a permanent position (which can be substantially identical to the temporary position a foriegner currently occupies). The employer has to prove that there is noAmerican to fill the job. This can be done in one of two ways: filing the petition, requesting RIR, or not. RIR is Reduction in Recruitment. It means that the employer is asking to not have to recruit for the position because of a recent (within the past 6 months) history of actively advertising, on a national level, to fill the position, without success. If RIR is not approved, the employer has to post an ad for the job in several national newspapers for at least 10 days, as well as on the job site. All candidates must be interviewed and their resumes forwarded to the State Department of Labor. The employer must hire an American that meets the minimum job qualifications before hiring the foriegner, even if his/her qualifications are better. Oh, and you can't artificially tailor the job requirements to the candidate. (In practice, this means that you can't be obvious about it.)
An RIR LC can take about 6 months. Mine took 5. A non-RIR LC can take several years to get approved (though 18 months is typical). Note, that unlike an LCA, which is a simple promise by the employer, an LC is subject to great scrutiny. The LC is said to be the biggest hurdle.
Once you get an LC (well, once the employer gets it for the position for which they want to hire you), it's time to file I140 - the immigrant visa petition. There are several priority queues for immigrant visas. Employment based are called EB1 (highest priority), EB2, and EB3 (lowest priority - duh!). EB1 is for people with skills of national interest to the U.S., those who are recognized as among the world's best in their fields -- Nobel Laureates, for example. EB2 is for people with advanced degrees, PhDs and Master's degrees. (I qualify for EB2 by virtue of my Master's degree in Computer Science). EB3 is everyone else. It takes from 6 months on for the INS to process an I140, depending on the processing center to which the petition is sent.
Along with the I140, you need to supply letters of reference and a resume as evidence that the foriegner has this skills for the job. The kicker is that the skill have to have been acquired before having worked in the U.S. (say, on a NAFTA or H1 visa).
I'm told that my I140 should take from 5 to 12 months to process.
When you file the I140, you have the choice to select AOS, or CPIV (though you can change this decision when the time comes to follow through). AOS means that once the I140 is approved, you apply to actually have your status changed from non-immigrant to immigrant. If not already working on a non-immigrant work visa, you can apply for EAD (which takes about 6 weeks), to start work. Your spouse and dependents can too. Spouses and dependents can generally enter on derivative visas (TD for TN, and H4 for H1) that don't let them work. In the case of immigrant visas, the annual cap applies to derivative visas which are as good as the main one. AOS can take from 6 to 24 months. 12 months is typical. During this time, you can't leave the U.S. (unless you apply for "Advance Parole" -- some have commented that since you are a prissoner of the INS processing queue, the term Parole is appropriate).
CPIV is different. With CPIV, you leave the U.S. to go to the consulate in your home country, armed with your approved I140, and complete the process there. It takes about 10 days, and involves, among other things, police fingerprinting, and
criminal background check. In both cases (AOS and CPIV), there is a country-specific limit on how many visas are granted in a year -- just because you can get one, doesn't mean that yo don't have to wait.
Bottom line: it isn't easy to get into the U.S. I don't think that skilled American tech workers need worry. While the system is abused by some employers, the employers should be brought before the INS, and resentment not leveled against the
workers (unless they're knowing participants in breaking the law).
My employer (Teradyne) is constantly looking for Americans with string embedded system and networking technical skills. I can't make any promises, but if you email me at hollan@enteract.com (rene@hollan.org has smtp troubles right now), I'll pass any resumes along to my HR department, in confidence.
More on applying for an immigrant visa while on a non-immigrant visa: The law recognizes the doctrine of dual intent. That is, you can intend to be in the U.S., temporarily for one job, while at the same time, seeking to immigrate on the basis of a permanent job. The legislation regarding H1 visas explicitly recognizes this, but that is not the case for NAFTA visas. Thus, many immigration attorneys won't try to pursue an immigrant visa while you're on NAFTA visa. Mine considers it too risky. Others (Joseph Grasmick, for one), do. The biggest difficulty is that you'll likely have to renew your NAFTA visa while your green card is pending, and that will be taken as non-temporary. It's splitting a pretty fine hair.
I'm amazed at the lack of talent I see applying for software engineering jobs.
First, some perspective: I'm a Canadian in the U.S. on an H1-B visa, so I'm rather interested in there is/isn't an IT shortage and foriegners do/don't take jobs away from Americans arguments.
Sometimes, I have to interview, or size up potential candidates, as one of many interviewers. I'm shocked at (a) how mediocre most are, and (b) how lax my coworkers are at accepting them as "good enough, because we won't find better". Only once have I pulled my manager out of the final interview with a candidate to tell him, "Don't let him leave without an offer" (which is very unusual).
One of my stock questions is this: "Write a function to accept an array of items, and sort them according to some ordering appropriate to the type of the items. You may use any language, and types of items (integers, floating point numbers, strings, etc.), but you will have to explain the complexity of the function in 'big-O(n)' notation. It doesn't have to be the most efficient algorithm."
I'm sufficiently versed in most programming languages, and know most common sort algorithms, to evaluate the result.
Guess what? 95% of the candidates can't do this!
I usually expect a bubble sort in C, C++, or Java (but BASIC, Python, or Fortran, would be O.K. APL or COBOL would be cheating, and I doubt that I'd see an Assembler implementation, but I could deal with most of those too).
Like I said, a bubble sort, with a discussion of the O(n^2) behavior would be great. (In practice, you'd use a commercial routine, or take the time to code an O(n log n) one). A properly coded Shell sort would also work (but not gain any extra points), and if you mention Ford-Johnson, you'd better be able to (a) provide an implementation, and (b) know the first few numbers for which it is optimal. Smartasses get marked harder, IOW. But most can't even provide a bubble sort!
So, I'd have to agree that there is a shortage of competent people, but a surplus of those entering the field for "easy money".
I have found that the difference between the "most productive" and "least productive" in this business is at least an order of magnitude.
The trouble, of course, is that the most productive get coopted into spending much of their time making up for the mis-efforts of the least productive, often to the detriment of their own assigned tasks. Call it "teamwork", or "loyalty", but it still sucks.
If you're lucky, you're manager will see the difference, but all too often, they are so clueless, that they are incompetent to tell one from the other. And incompetent team members sometimes make up for it politically, by casting out those who might expose their incompetence for what it is. This is called "not being a team player".
Even fix a problem on which a man-year has already been spent, in, say, an hour? Do that eight times a year, and you're 8 times more productive than the average, even if you do nothing else. Have you any idea how badly that fucks up management metrics? Not to mention foster insecurity and resentment among coworkers?
Then there's the "What do we do?...," "Do X...," "We can't do X...," time passes, "The competition did X! What now?..." scenario. Know how frustrating it is to have to out-design yourself? It sucks. But, I digress.
I'm slowly coming to the conclusion that the only solution is to become an independent contractor.
Well, with the case against 2600 surely going to appeal, and now this, I'm sure the EFF will have it's hands full.
I sent them $100 a while ago in a fit of temporary wealth. Maybe it's time to do it again. Yeah, I also bought Copyleft's anti-DVDCCA shirt (someone at work actually thought my posession of it was illegal without even caring whether such a law was just -- scary. Since I'm not in Judge Kaplan's judisdiction, I'm sure this isn't the case.)
Better yet, perhaps it's time to send, oh, I don't know $20 or $30 a month to the EFF on a regular basis. Anyone know if they accept ongoing contributions via credit card?
FWIF, I don't own a DVD player (and won't buy one unless I can view movies with free software), don't collect MP3s of copyright works, and will actually purchase a CD for one song, if I like it (though I'd prefer if the artist got more of my money for it.) Heck, I've purchased some CDs because I liked the cover art! (And have usually liked the music to boot.) I've boycotted movies (and amazon.com because of their stupid patent) for about six months now (not perfectly -- it's hard with a 7 year old, but cutting consumption is the important thing).
The frightening thing about this is that MPJDGI (Most People Just Don't Get It). They equate the internet as some kind of "interactive TV" in terms of "serving content", instead of a place where you get and share what you wish. An ignorant mob is a dangerous mob.
Also, the issues are so obvbious to "us" that often we don't even realize that "they" don't get it. Ever explain something to a wanna-be code jockey, only to have them program some real garbage? That's how dealing with "the masses" on these issues is.
While the DVD CCA, and MPAA have legitimate beefs against copyright violation, I fear that a great deal of baby is going to get thrown out with that particular brand of bathwater before this issue settles down.
Slashdot Mirror
Oh yes! I want one of these.... in a black case.
Right... and then you could cook on it too!
Well, yeah, that's the rub. I want to use it to pull uncompressed digital audio, and eventually MPEG2 video from over the home LAN, to drive (first) the stereo, and the high-res TV or monitor, respectively.
Thus, a fan is verboten.
I realize that hardware DVD decoding might require that level of active cooling, but surely a fanless solution exists that will at least do X and the digital audio stuff, leaving the video for later.
Even so, proper heat pipe technology should make it possible to use passive convection cooling. Look at the Mac Cube, for an example (and it doesn't even need a heat pipe).
Finally, I am willing to live with an outboard "brick" style power supply, if that helps remove the fan requirement.
Must: 100BT Ethernet
Must: 1600x1200x24bit SVGA graphics
Nice: 640x480x24bit 60Hz TV out via SVideo
Nice: TV tuner
Nice: HDTV tuner
Nice: FM tuner
Nice: DVI interface
Must: Hardware DVD playback support
Nice: Local DVD-ROM
Must: SPDIF or AES/EBU Digital audio out
Nice: externally clocked digital audio
Must: work with local or wireless (IR or RF) keyboard/mouse
Must: Boot from 'net or (better) FLASH
NO FAN!
Seriously, how do they deal with snow there? In Montreal (where I lived for 36 some odd years), the general rule is, big snow removal gear, running since early in the storm, and often. The downside is 2-3 feet high by 4-6 feet long by the width of the driveway of hard packed snow to clear (and a 10 foot high pile at the end of the front yard).
<Ob. Canadian "eh"> eh?
1. Yes, American beer is like sex in a canoe (fsking close to water), but I've never seen an American drink that swill -- the decent imported stuff is cheaper than soft drinks here.
2. Texas wild pigs vs. Moose: Imagine a small import car. Imagine it three times it's usual size, but with the same weight. Imagine it mad at you. You got moose. (They're essentially docile, and blind, but can get pretty mean if pissed off).
3. Canadians are world experts at telecom. They could probably coordinate a multi-city syncronized surprise attack from above. How much of telecom experts are Canadians? Canada is so big, with parts so remote, we shot up satelites with the sole purpose of delivering television to people... in the 1960s.
4. Failing a military-style assault, Canadians, well French Canadians from Quebec, could resort to a secret weapon: Poutine. It's got enough artery-clogging stuff to kill even the most insensitized couch potato. Consider it culinary warfare. Quebec soft drinks (to wash it down) contain triple the usual dose of sugar and so rot one's teeth to the point of rendering them ineffective -- the yanks couldn't even bite the invaders (and lest anyone think that Americans won't eat garbage, remember that they invented McDonalds, KFC, and, shudder, Taco Bell, complete with talking dog).
5. Canadians would attack in winter. From my experience, American cities and snow don't mix, becoming crippled with a 12 inch snowfall. Canadian cities get this about every 3-4 weeks in the winter. Nothing stops. Imaging a snowblower with a 100 inch wide and 36 inch tall maw, blowing snow 30 feet into the back of a truck (or your front yard). Imagine a vehicle big and strong enough to push the thing. Canadians know how to deal with snow. Americans don't even know what "snow tires" are. Yup, Canadians would attack in winter.
6. Celine Dion, Anne Murray, and Rita McNeal. What, you thought they were singers? Canadians think of them as "acoustic soldiers".
Picture this: you've sold thousands of remote units distributed all over the country that are tied into a communication network (er. TCP/IP/PPP over an X.25 SVC at a relatively low bit rate). Everything works until you start to download large amounts of data (i.e. a new software load). How do you fix it?
Answer: identify the combination of client and server TCP bugs that conspire to break long sessions; download a small code snippet that patches away enough of the bugs in place, so you can download a completely fixed app and new TCP/IP stack.
Ok, so it isn't thousands of miles UP, but it's thousands of times dozens of miles SIDEWAYS.
You can freely export open source strong crypto (which is probably already outside the U.S., so restrictions are pointless), as long as you do it in source form, and send a copy to the spooks.
Would you be willing to kill anyone who tried to stop you from reading this book allowed? Because that's what it might take, when they come after you. If you truly believe (at least in the U.S.A.) that you have a constitutional right to something (and this might not qualify, but serves as a useful example, and damn well should qualify), surely you can legally use deadly force in defending that right, commensurate with the efforts of those who would seek to deny you it.
So, I ask you, would you be willing to kill those who would seek to prevent you from reading to your children?
If not, then the battle is lost before it is begun, for all that it will take is someone using any force to stop you.
It was great when 20 Mb was a lot of data, but now, it's rather obsolete.
Alpha Micro is one of those orphan companies that just keeps going, and going, and going. They started life in 1976 with a 16 bit bit-slice CPU running on a modified S-100 (i.e. Altair) bus (these mods later became the IEEE 696 16-bit S-100 bus standard, IIRC). Came with an assembler, bytecode-compiled BASIC, and a multi-tasking, multi-user O/S (AMOS).
Yes, that was in 1976 -- pre IBM PC, pre Apple, pre CP/M, and espescially pre-Microsoft.
Sadly, the world went a different way (CP/M, DOS, Windows, and Unix (which was already around)), than did Alpha Micro. Still, they manage to stick around.
I had written LOTS of assembler code for that machine, including the SPY program, which allowed one terminal to shadow another one, even if they ran at different baud rates and used different screen control codes.
Ah, the memories.
I've already provided a copy of Maximum RPM as a reference (dated as it is), and sample .spec files, but still face resistance.
Heh. I've started to push the notion that the work product of our developers (who produce code for embedded RH 6.2 systems) should be an RPM and not merely "source code checked in to the source code control system" (unless that includes a .spec file).
First: Scalability. I want to be able to treat a set of packages as a single unit. It becomes unmanagable to set up a development environment for a particular product by requiring the installation of a dozen packages on top of a "stock" O/S installation. I've written a small Perl script to help me do this (since a script inside of an RPM spec file can't call RPM recursively due to its database lock). It supports notions of package set inheritence as well (so the foo development environment can include the generic development environment).
Second: source access. In a commercial environment, we can't go downloading and building packages from an external site. We need to ensure package consistency, and so cache all packages in our source code control system. It would be nice for a packaging system to allow specifications of multiple alternate source locations, and insisting on a particular one. It would be nicer if the package management system supported local or nfs path specs to such source. (RPM looks like it doesn't).
Third: Source Format. When building packages that we have not modified a tar or bzip source code archive is fine. However, for our own packages, we'd like to build from non-archived sourc code directories trees within the source code control system, since that's how our source code is managed.
Fourth: Source code references. When we include 3rd party RPMS of GPL code on a product distribution CD, we of course, have to also provide the corresponding source code on a companion source CD. It would be nice to match binary RPMS to source counterparts, and audit the match (so we don't have to build all such RPMS from source).
But this goes further than that. It explicitly codifies what such things are, protecting the coder. Furthermore, there's a whole 'nother aspect to this: the company that recycles Free (as in FSF) anf Open Source software in the products it produces.
Where I work we aggregate a great deal of code with Free software (specifically, major portions pf Red Hat [GNU/]Linux). Sometimes we extend GPL code (and will have to release our changes when we ship product). We've actually had RMS here to address our developers on the GPL and sensitize them to the fact that we take complience with it seriously. But, once you start using the fruits of the open and free sofware communuties, even if you ensure GPL complience, there's somewhat of a moral pressure to give something back, i.e. release your own original code as GPL, or otherwise open.
With this in mind, I've been striving for us to take the position that code we develop is either strategic to a product or product line, or not. If not, I argue that it should be GPL for two reasons: First, it helps make us good free and open software community corporate citizens. Second, it often represents overhead code that doesn't generate direct revenue through licensing, but requires support nevertheless. A community of people who can also use and extend it, is therefore a benefit. Sometimes we produce code that is stillborn: it would have to be released under the GPL if we distributed binaries, but we have decided not to make it part of a product. Why let such code rot? Why not give it away, in the hopes it might find a home?
Often, other than legal GPL complience, the effort to do these things is not justified by the company. an appropriate OSDA agreement would empower employees who feel this way, to release such code themselves, without fear of reprisials. That can only be a good thing.
The reason that yelling fire in a crowded theater when there is no fire is because there is no time for rational reflection, and not because somehow the right to free speech is protected.
heh... I first read that as "pornolithography" and not photolithography.
I used to play when I was younger. My father taught me the game, and I honed my skils in high school (some of my opponents were very good: one of them was the provincial champ for several years running). I got half-decent at it, but never exceptional.
Recent I had the pleasure of losing (as funny as that might sound) to a fellow I met in an "Einstein's Bagels": I had seen him play another once, and play several games out of an openings book, and he was willing to engage me in a game. Note: I hadn't played seriously in at least 20 years.
While I lost (Well, I resigned. The one redeeming fact was that I realized it was over earlier than most), it was a lot of fun.
- RSH
Your friend's exprience may suggests that her employer may be breaking the law.
I am a 39 year old Canadian citizen in the U.S. on an H1-B visa as well, and my employer has obtained a labour certification for a permanent position offered to me. More on that later. I arrived in the U.S. on a Nafta TN-1 visa on November 4, 1997, renewed once, and obtained an H1-B subsequent to my employer's petition in December of 1999.
Now, the TN-1, or NAFTA visa is open only to Canadians (with a TN-2 equivalent for Mexicans), for one year only, for a temporary position. It may be renewed indefinately, but your intent to stay in the U.S. is presumed to be temporary and that may be questioned if you have "too many" renewals. You need a degree from a recognized university or equivalent professional experience, and the job must be in one of several catagories. For example, systems analyst is a recignized profession, but programmer isn't. Basically, you show up at a U.S. port of entry with an offer letter from the U.S. employer that lists the job correctly, proof of your degree or experience, and proof of Canadian citizenship. There's a processing fee, US$50 when I went. You can renew either by mail or at a POE (port of entry). The salary is supposed to be commensurate with normal wages paid to Americans, but is not checked uness a complaint against the company is filed. You must support all U.S. social programs via your taxes, but may not benefit from them. You CAN benefit from public schools (for your kids) because they are generally funded from city property taxes and not federally. Now according to the NAFTA legislation, the degree doesn't have to match the job, but the INS officer has a great deal of discretion to deny you entry if it doesn't match. Tough. The presumption is that anyone entering the U.S. is doing so illegally, and you have to prove otherwise. Changing jobs isn't too bad: you have to get another TN-1 for the new employer, but I think you have to go to the border to do it. It's a bit tricky because you have to start work for the new employer shortly after entering the U.S. on the new TN-1. There is no limit on NAFTA visas, and the process can go quickly. Of course, you risk ending up on the wrong side of the border if something goes wrong.
The H1 visa is different. It's good for three years, renewable once. In order to be in H1 status again, you have leave the U.S. for a year. You CAN revert to a TN-1 if the six years are up, but the whole "temporary intent" issue may be questioned. AFAIK, lying to an immigration officer is a felony and may be grounds to be barred from entry to the U.S. for a ong time (I'm not sure how long).
H1 visas are availible for anyone, not just Canadians and Mexicans, like the NAFTA visas. There is an annual cap. To get one, the sponsering employer files an LCA (Labor Certification Attestment), which is a testiment that the foriegner will be paid the going wage in the industry, and isn't being hired to replace Americans locked-out or on strike. There may be restrictions regarding recent layoffs. So, if a company hires someone on an H1, and underpays them, a complaint to the INS is in order. Basically, such an employee can't be treated any worse than an American employee.
Now, I'll be the first to admit that there can be a difference between law and practice. I don't like to see H1 workers treated as indentured slaves and particularly underpaid, because it strengthens arguments by American workers that they take their jobs away. Of course, such arguments should be levelled at the employers violating the law.
A game often played with H1 tech workers is that, instead of being underpaid, they're overworked, forced to work overtime without pay. Since their presence in the U.S. depends on their employment, they can feel trapped. But, again, tech workers in general can be so treated, espescially in States that permit "exempt" employees to not be paid overtime. Still, it is difficult for the H1 worker to leave poor working conditions.
While it is possible for an H1 visa to be transferred to another employer, the actual process is time-consuming: the new employer has to get an LCA approved, file an petition to hire the H1 worker, and then the worker with the existing H1 visa can begin work for the new employer. A year ago, in Illinois, the process took four months. The current employer need NOT find out until the employee actually starts to work for the new employer, but you can only work for one employer at a time. If the current employer finds out vbefore the process is complete, the results may be disasterous: you have 10 days to leave the country.
Now, a bill currently in the process of moving to become law makes some changes to make it easier for H1 workers to migrate to better jobs, limiting opportunities for indentured serviture: you only have to have applied to begin the transfer process in order to start working for a new employer (but, if that is not approved, you have no safety net). In addition, people nearing the end of their H1 visa 6 year limit can get annual extentions while they have green card AOS (adjustment of status) pending. Contrary to at least one post here, you can apply for a Green Card while on an H1 visa (and even a NAFTA visa, though that's more iffy -- more later).
This used to be a big problem. Getting a green card (i.e. employment based immigrant visa), involves three steps, LC (labor certification), I140 immigrant petition, and AOS (adjustment of status), or CPIV (consular processing). This can take from one year to more than six years (hence the problem with H1 visas expiring).
The first step, LC, involves the employer applying for labor certification to hire a foriegner for a permanent position (which can be substantially identical to the temporary position a foriegner currently occupies). The employer has to prove that there is noAmerican to fill the job. This can be done in one of two ways: filing the petition, requesting RIR, or not. RIR is Reduction in Recruitment. It means that the employer is asking to not have to recruit for the position because of a recent (within the past 6 months) history of actively advertising, on a national level, to fill the position, without success. If RIR is not approved, the employer has to post an ad for the job in several national newspapers for at least 10 days, as well as on the job site. All candidates must be interviewed and their resumes forwarded to the State Department of Labor. The employer must hire an American that meets the minimum job qualifications before hiring the foriegner, even if his/her qualifications are better. Oh, and you can't artificially tailor the job requirements to the candidate. (In practice, this means that you can't be obvious about it.)
An RIR LC can take about 6 months. Mine took 5. A non-RIR LC can take several years to get approved (though 18 months is typical). Note, that unlike an LCA, which is a simple promise by the employer, an LC is subject to great scrutiny. The LC is said to be the biggest hurdle.
Once you get an LC (well, once the employer gets it for the position for which they want to hire you), it's time to file I140 - the immigrant visa petition. There are several priority queues for immigrant visas. Employment based are called EB1 (highest priority), EB2, and EB3 (lowest priority - duh!). EB1 is for people with skills of national interest to the U.S., those who are recognized as among the world's best in their fields -- Nobel Laureates, for example. EB2 is for people with advanced degrees, PhDs and Master's degrees. (I qualify for EB2 by virtue of my Master's degree in Computer Science). EB3 is everyone else. It takes from 6 months on for the INS to process an I140, depending on the processing center to which the petition is sent.
Along with the I140, you need to supply letters of reference and a resume as evidence that the foriegner has this skills for the job. The kicker is that the skill have to have been acquired before having worked in the U.S. (say, on a NAFTA or H1 visa).
I'm told that my I140 should take from 5 to 12 months to process.
When you file the I140, you have the choice to select AOS, or CPIV (though you can change this decision when the time comes to follow through). AOS means that once the I140 is approved, you apply to actually have your status changed from non-immigrant to immigrant. If not already working on a non-immigrant work visa, you can apply for EAD (which takes about 6 weeks), to start work. Your spouse and dependents can too. Spouses and dependents can generally enter on derivative visas (TD for TN, and H4 for H1) that don't let them work. In the case of immigrant visas, the annual cap applies to derivative visas which are as good as the main one. AOS can take from 6 to 24 months. 12 months is typical. During this time, you can't leave the U.S. (unless you apply for "Advance Parole" -- some have commented that since you are a prissoner of the INS processing queue, the term Parole is appropriate).
CPIV is different. With CPIV, you leave the U.S. to go to the consulate in your home country, armed with your approved I140, and complete the process there. It takes about 10 days, and involves, among other things, police fingerprinting, and criminal background check. In both cases (AOS and CPIV), there is a country-specific limit on how many visas are granted in a year -- just because you can get one, doesn't mean that yo don't have to wait.
Bottom line: it isn't easy to get into the U.S. I don't think that skilled American tech workers need worry. While the system is abused by some employers, the employers should be brought before the INS, and resentment not leveled against the workers (unless they're knowing participants in breaking the law).
My employer (Teradyne) is constantly looking for Americans with string embedded system and networking technical skills. I can't make any promises, but if you email me at hollan@enteract.com (rene@hollan.org has smtp troubles right now), I'll pass any resumes along to my HR department, in confidence.
More on applying for an immigrant visa while on a non-immigrant visa: The law recognizes the doctrine of dual intent. That is, you can intend to be in the U.S., temporarily for one job, while at the same time, seeking to immigrate on the basis of a permanent job. The legislation regarding H1 visas explicitly recognizes this, but that is not the case for NAFTA visas. Thus, many immigration attorneys won't try to pursue an immigrant visa while you're on NAFTA visa. Mine considers it too risky. Others (Joseph Grasmick, for one), do. The biggest difficulty is that you'll likely have to renew your NAFTA visa while your green card is pending, and that will be taken as non-temporary. It's splitting a pretty fine hair.
First, some perspective: I'm a Canadian in the U.S. on an H1-B visa, so I'm rather interested in there is/isn't an IT shortage and foriegners do/don't take jobs away from Americans arguments.
Sometimes, I have to interview, or size up potential candidates, as one of many interviewers. I'm shocked at (a) how mediocre most are, and (b) how lax my coworkers are at accepting them as "good enough, because we won't find better". Only once have I pulled my manager out of the final interview with a candidate to tell him, "Don't let him leave without an offer" (which is very unusual).
One of my stock questions is this: "Write a function to accept an array of items, and sort them according to some ordering appropriate to the type of the items. You may use any language, and types of items (integers, floating point numbers, strings, etc.), but you will have to explain the complexity of the function in 'big-O(n)' notation. It doesn't have to be the most efficient algorithm."
I'm sufficiently versed in most programming languages, and know most common sort algorithms, to evaluate the result.
Guess what? 95% of the candidates can't do this!
I usually expect a bubble sort in C, C++, or Java (but BASIC, Python, or Fortran, would be O.K. APL or COBOL would be cheating, and I doubt that I'd see an Assembler implementation, but I could deal with most of those too).
Like I said, a bubble sort, with a discussion of the O(n^2) behavior would be great. (In practice, you'd use a commercial routine, or take the time to code an O(n log n) one). A properly coded Shell sort would also work (but not gain any extra points), and if you mention Ford-Johnson, you'd better be able to (a) provide an implementation, and (b) know the first few numbers for which it is optimal. Smartasses get marked harder, IOW. But most can't even provide a bubble sort!
So, I'd have to agree that there is a shortage of competent people, but a surplus of those entering the field for "easy money".
Face it, very few can do what we do.
... subject says it all.
I have found that the difference between the "most productive" and "least productive" in this business is at least an order of magnitude.
The trouble, of course, is that the most productive get coopted into spending much of their time making up for the mis-efforts of the least productive, often to the detriment of their own assigned tasks. Call it "teamwork", or "loyalty", but it still sucks.
If you're lucky, you're manager will see the difference, but all too often, they are so clueless, that they are incompetent to tell one from the other. And incompetent team members sometimes make up for it politically, by casting out those who might expose their incompetence for what it is. This is called "not being a team player".
Even fix a problem on which a man-year has already been spent, in, say, an hour? Do that eight times a year, and you're 8 times more productive than the average, even if you do nothing else. Have you any idea how badly that fucks up management metrics? Not to mention foster insecurity and resentment among coworkers?
Then there's the "What do we do?...," "Do X...," "We can't do X...," time passes, "The competition did X! What now?..." scenario. Know how frustrating it is to have to out-design yourself? It sucks. But, I digress.
I'm slowly coming to the conclusion that the only solution is to become an independent contractor.
You might find http://www.hollan.org/steg.txt interesting.
- RSH
I've met RMS. He appeared to be of average (male) height to me: perhaps 5'10" to 6' tops. FWIW, I'm shorter than average, at 5'7" - RSH
Well, with the case against 2600 surely going to appeal, and now this, I'm sure the EFF will have it's hands full.
I sent them $100 a while ago in a fit of temporary wealth. Maybe it's time to do it again. Yeah, I also bought Copyleft's anti-DVDCCA shirt (someone at work actually thought my posession of it was illegal without even caring whether such a law was just -- scary. Since I'm not in Judge Kaplan's judisdiction, I'm sure this isn't the case.)
Better yet, perhaps it's time to send, oh, I don't know $20 or $30 a month to the EFF on a regular basis. Anyone know if they accept ongoing contributions via credit card?
FWIF, I don't own a DVD player (and won't buy one unless I can view movies with free software), don't collect MP3s of copyright works, and will actually purchase a CD for one song, if I like it (though I'd prefer if the artist got more of my money for it.) Heck, I've purchased some CDs because I liked the cover art! (And have usually liked the music to boot.) I've boycotted movies (and amazon.com because of their stupid patent) for about six months now (not perfectly -- it's hard with a 7 year old, but cutting consumption is the important thing).
The frightening thing about this is that MPJDGI (Most People Just Don't Get It). They equate the internet as some kind of "interactive TV" in terms of "serving content", instead of a place where you get and share what you wish. An ignorant mob is a dangerous mob.
Also, the issues are so obvbious to "us" that often we don't even realize that "they" don't get it. Ever explain something to a wanna-be code jockey, only to have them program some real garbage? That's how dealing with "the masses" on these issues is.
While the DVD CCA, and MPAA have legitimate beefs against copyright violation, I fear that a great deal of baby is going to get thrown out with that particular brand of bathwater before this issue settles down.
Rene S. Hollan
Personally, I rarely give money to vagrants (or buy them food). I do sometimes though.
What I do as a regular matter of course, though, is tip well. Serving other people has to be one of the toughest things in the world.
He evangelizes the GPL -- promotes it if you will. And, he's admitted that he's an atheist.