Many people are still under the impression that H1B visa holders are sort of stuck, finding it difficult to change employers. This is certainly not the case now, as a FAQ on the new law shows. A highlight:
Q6. Does the law make it easier for an H-1B worker to change employers?
A. Yes it does. Section 105 allows an H-1B worker to change employers as soon as his
or her new employer submits a "nonfrivolous" H-1B petition to the INS. Prior law requires that a worker wait until the petition is approved before changing employers.
I don't have the INS letter that Shusterman posted a while ago, but it is clear from that letter that this provision has already been implemented. A company has little incentive to recruit H1B workers -- and deal with the paperwork -- with the intention of underpaying them, since the visa-holders can easily jump to another, better-paying company with little difficulty.
Seriously, would anyone try to grab a PC sitting on a sidewalk? If you see a box there, it usually means "I'm so obsolete I can't be sold: please take me!". I often see these pieces of junk in my neighborhood: who wants them? Even if they worked before, the rain and elements would have ruined them. Forget the concrete. You won't need it.
Would have been news 3 years ago
on
Books on Demand
·
· Score: 2
This would have been news 3 years ago. Actually, it was news 3 years ago. For instance, Wired had a article on this on June 16, 1998. Xerox and IBM have had machines to do this job for ages, so I don't see why this is big news now. I recall that Borders was planning to offer this service in their bookstores (obviously, this did not happen).
There are still unresolved issues. For example, convincing numerous copyright holders to allow on-demand printing. A former colleague worked on a startup with similar goals, but never got past the legal and funding issues. If even Borders could not pull this off, who could? There is also the problem of contracts. Many publishers' agreements with authors have clauses that depend on when the book goes out of print. In electronic publishing, the title never goes out of print.
I would love to see books-on-demand really take off... 3 years ago. I'm still waiting.
Are you sure you are talking about current flourescent lights? The old ones were flickery and gave poor light, but the new ones (such as the compact flourescents talked about) are much better.
Major household appliances are all AC devices. Solar cells generate DC. How does one bridge the gap without custom-made appliances, and what is the efficiency hit of that?
Last time I saw a memory usage figure for Galeon, it was no smaller than Mozilla's, weighing in at an elephantine 30MB or so. Few modern graphical browsers are
as small as Opera, but they can surely do better than that. Anyone has a memory
usage figure for the current Galeon? Thanks.
There is a difference between ownership and license type. GPL is a license: anyone who writes code can release it under GPL and still retain copyright over his. It would not be accurate to call this code GNU code. So the case for calling Linux "GNU/Linux" is not that strong. Last time I saw an accounting of this sort, stuff from the Free Software Foundation -- software that can properly be called GNU -- made up under 10% of a Linux distribution. Lots of software is released under GPL these days, even Qt. To paint over them with the broad GNU brush would be a disservice to non-GNU contributors to Linux.
Also, KDE would rank quite a bit higher if it did not get listed as separate components: kdebase, kdelibs, koffice, kdemultimedia etc. It looks like a sort of statistical gerrymandering. After all, GNU projects like emacs and gcc did not get separated into smaller components, even though they are packaged in pieces. Why is KDE treated differently?
Just a simple issue: photovoltaics generate DC. Grid electricity provide AC and most appliances use AC. Seems like there is a certain cost involved in converting DC to AC. What are the costs and efficiencies involved?
You are citing Japanese material. The cost structure and energy costs there are rather different from wherever the original poster is residing. Without real data, it is not possible to extrapolate to other locations.
I've been tracking the "Received" lines for a long time. But it is often difficult or impossible, even with the correct address, to send a complaint. The spam tends to get routed through a hijacked mail server, which in return often does not include the originating spammer's IP address. And if the hijacked server is not in the US, things get more complicated. I have received a lot of spam from Korea lately, where the mail server's hostname is not available (only its IP), and whois only turns up the country's national network contacts. Additionally, many of these hijacked hosts do not have valid postmaster addresses. From some discussions I've read, some countries' ISPs are notoriously unresponsive. They may not understand English, after all.
Ah, but most of them make the ISPs do the work for them. They may have fat pipes, but they are not used for much of the spamming. They hijack mail servers, pile on the addresses, and make THEM do the hard work of delivering each address. I have not received any spam in recent memory that came directly from the spammer's machine. They all came from hijacked mail servers. When porn sites do use their heavy duty bandwidth to deliver porn, it is to serve a revenue-generating audience that pays for it. The problem is when they force ISPs to pay for their advertising.
I know curses/ncurses is ubiquitous, but it is not a UI library. I don't understand why people keep recommending ncurses or Slang for application development: it's like recommending an axe and a cow when someone orders a medium rare filet mignon. A modern UI library -- text or graphics -- is far more than the ability to draw text on the screen, even with panels or windows. The UI widgets that we take for granted with modern UI libraries are completely absent from Curses or Slang: scroll bars, buttons, entry fields with masks, drop down menus, check boxes, radio buttons, grid controls... etc. Even a touch screen POS will find many of these UI elements relevant.
Try something like Xterminal if you are using C++, or CDK or Newt otherwise. These libraries are typically built on top of ncurses and/or Slang, sort of like how Qt/Gtk+ are built on X Windows.
Last I looked at it, Newt documentation was nonexistent. Documentation is a seldom appreciated feature, and it's hard to gauge a library's capability -- let alone use it -- without decent documentation. Also, it lacked a grid/table widget that I needed.
One of the developments not mentioned but important is that Mandrake is once again binary-compatible with Red Hat. Now that rpm (version 4), glibc (2.2) and gcc (2.96-RH) are in sync between Mandrake 8 and Red Hat 7, RPMs can be interchanged freely between two of the largest Linux distributions. This is a good thing, regardless of which of the two you prefer. This should also further legitimize gcc 2.96-RH, which apparently is quite stable now.
The kdeinit process speeds up app loading, since KDE apps link to a lot of shared libraries and kdeinit is linked to those. By forking off new processes rather than having a new process link to all those shared libs as it starts, time and memory is saved. But the code is not really in memory if you don't use it. Konq loads a lot faster if Kmail is displaying HTML pages, for example. That is because khtml is loaded. On the other hand, free memory increases by quite a chunk when I shut down Konq and no other app is displaying HTML. So it is not true that Konq is always in memory. It certainly isn't on my KDE desktop.
Galeon may not be the answer
on
QT Mozilla Port
·
· Score: 1
The last time I saw numbers for Galeon's memory footprint, it seems to be almost as big as Mozilla. It is just as bloated, memory-wise. In addition, you will need Gnome installed. I saw no mention of Javascript or HTTPS on the Galeon pages: does it have those? A browser that is too stripped down will not be useful.
Every memory usage report I have seen shows that Galeon eats roughly as much memory as Mozilla itself. It may be light on features, but in terms of footprint it is just as bloated.
For the forseeable future, a slow browser will still look sluggish next to a faster one, even on a fast PC. I am still surprised at how fast Opera feels right now, compared to any other browser. Even after upgrading to a PC that is several times faster than my old one, I can see the difference. Opera excels in rendering out of a cache: try hitting the "back" and "forward" buttons to see its speed.
Chris
Plain RPC is Unix-ish too
on
ESR On XML-RPC
·
· Score: 1
Why reinvent the wheel when RPC already provides cross-language, cross platform remote procedure calls at much lower overhead?
What's wrong with good ol' RPC?
on
ESR On XML-RPC
·
· Score: 2
I'm working on a C/Java project that uses plain old RPC (yes, there are RPC implementations in Java), and it works reasonably well. This topic puzzles me. What exactly does XML-RPC have that justifies a whole new method of doing remote procedure calls? That is, apart from the extra overhead and bypassing firewalls (thus negating their usefulness).
It's not that hard to read HTML even on text-mode mail readers. Pine already parses HTML, for one. For mutt, it's just a matter of putting "auto_view text/html" in your.muttrc, an appropriate command in your mailcap ("w3m -T text/html -dump %s", or "lynx -force_html -dump %s") and setting the mailcap path in.muttrc.
Slashdot Mirror
Many people are still under the impression that H1B visa holders are sort of stuck, finding it difficult to change employers. This is certainly not the case now, as a FAQ on the new law shows. A highlight:
Q6. Does the law make it easier for an H-1B worker to change employers?
A. Yes it does. Section 105 allows an H-1B worker to change employers as soon as his or her new employer submits a "nonfrivolous" H-1B petition to the INS. Prior law requires that a worker wait until the petition is approved before changing employers.
I don't have the INS letter that Shusterman posted a while ago, but it is clear from that letter that this provision has already been implemented. A company has little incentive to recruit H1B workers -- and deal with the paperwork -- with the intention of underpaying them, since the visa-holders can easily jump to another, better-paying company with little difficulty.
We've had thin CRTs since the 80s. Remember Sinclair's flat screen TV? :-)
Seriously, would anyone try to grab a PC sitting on a sidewalk? If you see a box there, it usually means "I'm so obsolete I can't be sold: please take me!". I often see these pieces of junk in my neighborhood: who wants them? Even if they worked before, the rain and elements would have ruined them. Forget the concrete. You won't need it.
This would have been news 3 years ago. Actually, it was news 3 years ago. For instance, Wired had a article on this on June 16, 1998. Xerox and IBM have had machines to do this job for ages, so I don't see why this is big news now. I recall that Borders was planning to offer this service in their bookstores (obviously, this did not happen).
... 3 years ago. I'm still waiting.
There are still unresolved issues. For example, convincing numerous copyright holders to allow on-demand printing. A former colleague worked on a startup with similar goals, but never got past the legal and funding issues. If even Borders could not pull this off, who could? There is also the problem of contracts. Many publishers' agreements with authors have clauses that depend on when the book goes out of print. In electronic publishing, the title never goes out of print.
I would love to see books-on-demand really take off
Are you sure you are talking about current flourescent lights? The old ones were flickery and gave poor light, but the new ones (such as the compact flourescents talked about) are much better.
Major household appliances are all AC devices. Solar cells generate DC. How does one bridge the gap without custom-made appliances, and what is the efficiency hit of that?
Last time I saw a memory usage figure for Galeon, it was no smaller than Mozilla's, weighing in at an elephantine 30MB or so. Few modern graphical browsers are
as small as Opera, but they can surely do better than that. Anyone has a memory
usage figure for the current Galeon? Thanks.
There is a difference between ownership and license type. GPL is a license: anyone who writes code can release it under GPL and still retain copyright over his. It would not be accurate to call this code GNU code. So the case for calling Linux "GNU/Linux" is not that strong. Last time I saw an accounting of this sort, stuff from the Free Software Foundation -- software that can properly be called GNU -- made up under 10% of a Linux distribution. Lots of software is released under GPL these days, even Qt. To paint over them with the broad GNU brush would be a disservice to non-GNU contributors to Linux.
Also, KDE would rank quite a bit higher if it did not get listed as separate components: kdebase, kdelibs, koffice, kdemultimedia etc. It looks like a sort of statistical gerrymandering. After all, GNU projects like emacs and gcc did not get separated into smaller components, even though they are packaged in pieces. Why is KDE treated differently?
Just a simple issue: photovoltaics generate DC. Grid electricity provide AC and most appliances use AC. Seems like there is a certain cost involved in converting DC to AC. What are the costs and efficiencies involved?
You are citing Japanese material. The cost structure and energy costs there are rather different from wherever the original poster is residing. Without real data, it is not possible to extrapolate to other locations.
I've been tracking the "Received" lines for a long time. But it is often difficult or impossible, even with the correct address, to send a complaint. The spam tends to get routed through a hijacked mail server, which in return often does not include the originating spammer's IP address. And if the hijacked server is not in the US, things get more complicated. I have received a lot of spam from Korea lately, where the mail server's hostname is not available (only its IP), and whois only turns up the country's national network contacts. Additionally, many of these hijacked hosts do not have valid postmaster addresses. From some discussions I've read, some countries' ISPs are notoriously unresponsive. They may not understand English, after all.
Ah, but most of them make the ISPs do the work for them. They may have fat pipes, but they are not used for much of the spamming. They hijack mail servers, pile on the addresses, and make THEM do the hard work of delivering each address. I have not received any spam in recent memory that came directly from the spammer's machine. They all came from hijacked mail servers. When porn sites do use their heavy duty bandwidth to deliver porn, it is to serve a revenue-generating audience that pays for it. The problem is when they force ISPs to pay for their advertising.
Try something like Xterminal if you are using C++, or CDK or Newt otherwise. These libraries are typically built on top of ncurses and/or Slang, sort of like how Qt/Gtk+ are built on X Windows.
Last I looked at it, Newt documentation was nonexistent. Documentation is a seldom appreciated feature, and it's hard to gauge a library's capability -- let alone use it -- without decent documentation. Also, it lacked a grid/table widget that I needed.
One of the developments not mentioned but important is that Mandrake is once again binary-compatible with Red Hat. Now that rpm (version 4), glibc (2.2) and gcc (2.96-RH) are in sync between Mandrake 8 and Red Hat 7, RPMs can be interchanged freely between two of the largest Linux distributions. This is a good thing, regardless of which of the two you prefer. This should also further legitimize gcc 2.96-RH, which apparently is quite stable now.
The kdeinit process speeds up app loading, since KDE apps link to a lot of shared libraries and kdeinit is linked to those. By forking off new processes rather than having a new process link to all those shared libs as it starts, time and memory is saved. But the code is not really in memory if you don't use it. Konq loads a lot faster if Kmail is displaying HTML pages, for example. That is because khtml is loaded. On the other hand, free memory increases by quite a chunk when I shut down Konq and no other app is displaying HTML. So it is not true that Konq is always in memory. It certainly isn't on my KDE desktop.
The last time I saw numbers for Galeon's memory footprint, it seems to be almost as big as Mozilla. It is just as bloated, memory-wise. In addition, you will need Gnome installed. I saw no mention of Javascript or HTTPS on the Galeon pages: does it have those? A browser that is too stripped down will not be useful.
Every memory usage report I have seen shows that Galeon eats roughly as much memory as Mozilla itself. It may be light on features, but in terms of footprint it is just as bloated.
For the forseeable future, a slow browser will still look sluggish next to a faster one, even on a fast PC. I am still surprised at how fast Opera feels right now, compared to any other browser. Even after upgrading to a PC that is several times faster than my old one, I can see the difference. Opera excels in rendering out of a cache: try hitting the "back" and "forward" buttons to see its speed.
Chris
Why reinvent the wheel when RPC already provides cross-language, cross platform remote procedure calls at much lower overhead?
I'm working on a C/Java project that uses plain old RPC (yes, there are RPC implementations in Java), and it works reasonably well. This topic puzzles me. What exactly does XML-RPC have that justifies a whole new method of doing remote procedure calls? That is, apart from the extra overhead and bypassing firewalls (thus negating their usefulness).
I see no mention of Python. Will we ever see a version of Python newer than 1.5.2?
Memories can be hazy. You mean this little graph over here? Oh wait, that's solar activity vs climate. Oopsie. Excellent correlation too. Chris
It's not that hard to read HTML even on text-mode mail readers. Pine already parses HTML, for one. For mutt, it's just a matter of putting "auto_view text/html" in your .muttrc, an appropriate command in your mailcap ("w3m -T text/html -dump %s", or "lynx -force_html -dump %s") and setting the mailcap path in .muttrc.
My favorite quote is:
That's why we have moderators on SlashDot.