Since I've already paid for GPRS access on my mobile phone, I'll just use my GPRS thanks. Although it's only 64kbit/s, for going on IRC, writing emails and Slashdotting it's more than adequate, and it works well on the train as well as in airports.
However, GPRS
tends to get interrupted when other things happen on the phone (i.e. receive call or text message on my Nokia 6310i),
is often not very reliable on either the UK's east or west coast main line (i.e. London to Leeds or London to Manchester)
is expensive if you use it regularly; my Sept 2004 GPRS bill was £ 820...
I haven't been following LKML, but is Tridge's code available? It would seem likely that it would be useful to be able to extract as much meta-information from the Linux BitKeeper archive as possible.
I don't know how advanced Tridge's tools are, but GNU CSSC (downloadable from the the GNU FTP servers) has a certain amount of read-only compatibility with BitKeeper. See also the BitBucket
project (code here).
Larry never exposed BK source code, the code being pulled is the Linux kernel, it's just being pulled off a BK repository, which it is perfectly OK to do.
Actually Larry has indeed exposed BK source code. He released source for BitSCCS which is part of the underpinnings of BitKeeper.
Except that they don't quite seem to
get it yet. They are
offering
here some videos from
this
car programme which apparently didn't quite make
it to air,
In fact, the race between the Porsche Boxster and the BMW Z4
aired in the UK last night at 20:30. Hence I think the segments available for download relate to things in the current series of Fifth Gear. I don't know if the downloadable video includes footage beyond the amount that aired though. I can't think of any other reason to pay £1.50 for it.
The company has two options: they can either license their changes under the GPL, or they can distribute the original, unmodified program and a bunch of diffs.
I'm pretty certain that the diffs would be a derived work as well.
Why bother keeping IA-64? Debian has more alpha users than ia64. There are more SPARC users. Heck, there are even more HPPA users than ia64 users.
All the details are available at the
Debian Popularity Contest.
Sun also has a good record for maintaining compatibility to older versions of Solaris.
Not always; for example, the pixrect support in SunOS 4 was removed in SunOS 5. That made lots of useful things (espectially the console accelerator that made the console work at a reasonable speed) stop working.
LISP provides the eq? function which decides if its two operands are the same object:
(not (eq? a b))
The above does the same thing as IsNot. LISP was developed between 1958 and 1962. I'm sure that this idiom was in use back then. However, I don't have a copy of the original source "The LISP Report". Looking at an online copy of the well-known Computer Science book "Structure and Interpretation of Computer Programs," by Abelson, Sussman, and Sussman (published 1996), we see that they describe "eq?". The relevant bit of the book is
available online.
The
earliest version of Emacs I can lay my hands on dates from 1992. Searching it for occurrences of "(not (eq" reveals lots of hits. One of them (hanoi.el) is from a file last modified in 1987.
So clause 1 of the patent is not novel, and the idea existed widely in the literature and publicly available information at least 18 years before the patent was filed, and quite possibly as much as 42 years.
I think DTrace is available on Linux. It's called DProbes, and was invented by IBM. I have only read the Sun DTrace technical manual the once, but I think there are strong similarities. IBM's DProbes have been around for ages, too - since 2000, according to the ChangeLog, but I didn't hear about it until Richard Moore did a presentation
at the
UKUUGconference in Manchester in 2001.
Fact: Something that you observe to be true.
fact #1: when you drop a hammer, it falls to the ground
fact #2: a genetic sequence can change sufficiently to form a new species. Speciation has been observed more than once in the laboratory and in the wild, so this is a fact. Since we call this process 'evolution', that means evolution is a fact. Keep reading for more explanation of this.
This is subtly wrong. You need to read some real books on philosophy or logic (for example, Bertrand Russel's History of Western Philosophy or some Karl Popper perhaps). Briefly, though:
Fact: Something that you observe to be true.
fact: when I dropped a hammer this morning, it appeared (from where I was observing it) to fall to the ground
Theory: A prediction of future behaviour (usually on the basis of evidence)
Theory #1: If I drop a hammer tomorrow, near the surface of the Earth, it will fall towards the Earth's centre.
Theory #2: Objects having the property of "mass" are mutually attracted to each other. Further observation may reveal how the attractive force depends on the properties of those objects.
My point is that even the law of gravitation is not a "fact", because it is a prediction of future behaviour based on the previous observation of the Universe. It is crucial that in important debates like this one that proponents of rantionalism and modern scientific orthodoxy are very careful to be clear on their terms. Muddying terms and ambiguous use of vocabulary are a very good way for people to present a well-established scientific position as being open to doubt and multiple interpretation.
I'm no believer in Intelligent Design myself, but I find the arguments of the nerves in the giraffe's neck and other arguments to be more convincing than hairsplitting over "theory" versus "fact".
Re:number of interviews is not excessive
on
Defining Google
·
· Score: 1
I don't think that 14 interviews is really excessive. It depends on how you count them. If each 1/2-1 hour spent with an individual counts as an interview then it would be pretty easy to do 8-10 interviews in a day.
[...]
Most big software companies seem to have interview processes that are similar to this.
No way. I would never expect to spend only 30 minutes interviewing somebody. Normally, the interview has to cover much more material than could be covered in that time. The only exception might be if the candidate is wholly unsuitable leading to early termination of the interview, but must of those should be weeded out before the candidates get to interview. Most interviews I do last between 90 and 120 minutes.
However, that's not the main reason you're wrong, at least in the context of the large software company where I work (about 20k employees, of whom probably 70% are software professionals). After a one-hour interview (which is shorter than any real interview I've ever done) I would expect to spend at least 45 minutes writing up the result of that interview - deciding whether or not to offer the candidate a role, what role to offer them, how to grade them (essentially, how good they are and what salary to offer). It's even worse for panel interviews because the interviewers also have to discuss the candidate afterwards, which is going to take another 30 minutes or so.
A couple of times I've had to do interviewing full-tilt and for one-on-one interviews the most I've done was probably three or four in a day. Doing more than that means that you have to defer the paperwork until the following day. That's almost always bad because it's essential to keep the candidates straight in your mind when doing the assessment.
Why, you may ask, so much paperwork? Simply put, the candidate has the right (at least in this country) to enquire as to why they were not offered a job. You have to be able to give specific, reasonable and legally justiufiable reasons. Secondly, if you offer them a job and they turn out to be useless or not well suited to their new role, questions will come back to you as to why you hired them. Thirdly, the interview mostly determines the starting salary (along with previous salary and the industry going rates for those types of skills). Therefore it's pretty important to get that right - offer the wrong salary and you won't get the good candidates.
I cannot believe there were so many errors in an article which is only 358 words long. What a bad piece of journalism. Only 81 words are devoted to the China new item, the rest ss background on IPv6. The IPv6 information is riddled with errors.
Is it customary to count the number of words in an article?
It struck me as a very short article with a large number of errors. With "wc -w" it's easy to count the words. You didn't think I did it by hand, did you?
I cannot believe there were so many errors in an article which is only 358 words long. What a bad piece of journalism. Only 81 words are devoted to the China new item, the rest ss background on IPv6. The IPv6 information is riddled with errors.
There is a rather better
article on the subject of IPV6 adoption at
InternetWeek,
but that article is now four years old.
As for the specific information in the article, "IPv6 provides billions more IP addresses"
- I think the reporter is a bit confused about all these large numbers. IPv6 provides billions of
TIMES more addresses. More even than that in fact; 2 to the power 128 is 79228162514264337593543950336 times greater than 2 to the power 32. (This calculation was brought to you by GNU bc)
"It was created and deployed in response to... especially as Web use in Asia rises sharply." - The author has fallen for the post hoc ergo propter hoc fallacy. In any case, the beginning of the development of IPv6 occurred significantly before the extensive takeup of Internet technologies in Asia.
As other people have already mentioned (including in the reader comments below the article - I would have contributed but see no point in "registering" with CNET), goodness knows where the journalist got their figure of "257 nodes". They should perhaps take the time to either check their notes or cross-check the information their sources are giving them.
Something the author failed to point out is that it is not only Asian countries that have been working with IPV6. There has been significant piloting in most countries that make use of the Internet.
This means that there are IPV6 over IPv4 tunneling facilities that work therse days, meaning that it is not necessary for countries up upgrade everything to IPv6 in order for their businesses to trade with China, no matter what the article implies.
Firstly, my experience also bears out the "use a real slide scanner" response. These days I use a Nikon Coolscan V. The TIF files come out at about 138Mb. I'm a Linux zealot, it must be said (I maintain findutils, for example) but I have a laptop that runs Windows which work provides, and for photo work I use that, with Nikon Scan and Photoshop Elements.
I've found that VueScan (not Free software, but it does work under Linux and there is an edition that costs nothing) gives good results, and the multi-scan feature is especially good. However, there are two problems with using Linux downstream from that point. Firstly, the GIMP doesn't support colour depths greater than 8 bits, while my slide scanner produces 14 bits of colour depth (or 8 if you don't want 14). It's a shame to have to throw away those extra 18 bits of information per pixel.
Having said this, Photoshop Elements has the same limitation, though I'm sure that the premium Photoshop product does not. The Nikon scan tools don't. I use Photoshop Elements but not GIMP. The reaon why is a bit hard to pin down but it comes down to usability. The layering and selection tools in Photoshop Elements are more suited to doing photo manipulation than the ones in GIMP. Also, if you have a complex selection, Photoshop Elements is noticably more responsive on Windows than GIMP is on Linux on the same hardware. GIMP isn't actually sluggish, but PhotoSchop is more responsive and hence certainly easier to use.
I use Linux for exerything else (except a few bits at work) and I wish this wasn't true, but I find that Windows is indeed a better platform for photo work. That's ignoring the whole area of printing, too. Finding a printer that produces high-quality results which works under Linux is easy; finding one that the vendors still sell is much harder. I don't have a lot of time to devote to that search, so I haven't bought a printer yet.
In fact, I wish there were businesses that would sell "Lilnux compatible" hardware. I wouldn't look for support, and I'd pay a premium. I'd just like to be able to buy stuff from someone who can say "I got it to work with Linux".
Despite only having 2% of the installs, TinyDNS serves 15% of all domains on the internet.
Maybe that just means that TinyDNS is popular with domain squatters.
I think that the best definition of "heavy lifting" is not the size of the installed base or the average number of domains per server, but instead the total number of queries served. Those numbers of course are hard to estimate.
Its config file syntax is even more human-unfriendly than BIND's
It doesn't allow free reign to set the records up exactly how you want (trivially for example, it forces you to adopt a mandatory naming convention for MX records - though the convention is pretty sensible)
It doesn't support caching, so you need a separate server for that (this is actually good, but it does add to the overall amount of work required to set up a set of DNS servers)
Some people find DJB difficult to get on with and/or were turned off by the whole problem around (non) distribution of modified versions of qmail, and so avoid DJB's other offerings
I get the impression that when you move above vanilla C code (eg C++, libraries distributed in binary form only), different compilers don't play so nicely. (Just like gcc 2.9x versus gcc 3.x).
This is normally true, but there is one interesting exception - Intel ia64. That has a C++ ABI allowing C++ code built with any confirming compiler to link with code built with another conforming compiler. In other words, the sort of thing we are normally used to on Unix with C. The specification is here.
In fact the UK and US copyright laws are not so similar. I believe that this is why so many UK books are labelled "not for sale in the USA". This may be a historic thing in that US copyright law was changed many years ago so as not to require "registration" though.
One other difference between the two these days is in the area of non-transferrable copyrights. Of the seven or so distinct copyrights enjoyed (initially) by the author of a work, two cannot be transferred to any other party (even if the author wishes). These are:-
The right of paternity - that is, the right to be identified as the author of the work
The right of integrity - the right to object to derogatory treatment of a work (e.g. authors of books can object to adaptations of the book in other forms that they find morally or otherwise offensive)
Since Sun bought "rights" to UNIX from SCO some time ago, I think they can call it UNIX. Otherwise it would be Sunix and the President would need to change his/her last name to Sunis:P
There is a screenhack which is part of
Jamie Zawinski's
xscreensaver
that demonstrates epicycles. Oddly enough, it's called "epicycle". You can also run it directly like this:-
/usr/lib/xscreensaver/epicycle
The
epicycle manpage
also has a HISTORY section which explains a bit about the history of the idea. It says:-
The geometry of epicycles was perfected by Hipparchus of Rhodes at some time around 125 B.C., 185 years after the birth of Aristarchus of Samos, the inventor of the heliocentric universe model. Hipparchus applied epicycles to the Sun and the Moon. Ptolemy of Alexandria went on to apply them to what was then the known universe, at around 150 A.D. Copernicus went on to apply them to the heliocentric model at the beginning of the sixteenth century. Johannes Kepler discovered that the planets actually move in elliptical orbits in about 1602. The inverse-square law of gravity was suggested by Boulliau in 1645. Isaac Newton's Principia Mathematica was published in 1687, and proved that Kepler's laws derived from Newtonian gravitation.
Slashdot being what it is, I'm sure there are readers who have corrections to the above. If you do, please post them as followup or email them to me.
While some people always propagate the use of generics/templates, I'm strictly set up against it....
The type checking is much weaker thus introducing new potential holes for error to slip through.
You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.
With templates - and I assume generics, though I have not yet tried the 1.5.0 SDK - the type checking is stronger, not weaker. For example if you have a HashMap<InetAddress,HostIcon> then you can only retrieve items from it by specifying an InetAddress as a key, and it will only ever return instances of HostIcon. More importantly, this is checked at the time that your code is compiled.
If you need to make an assumption about the classes on which you operate, you can either just perform the operation you need (static compile-time checking will usually cause a compile-time error when the class on which you are operating does not give the requisite guarantee, for example, offer the method you need) or, failing that, you can use the Java language feature which was designed to comminicate interface contracts between classes and their users - that is, use an Interface.
Reminds me of British police
in the days when they didn't carry guns.
Stop, or I'll yell, "Stop" again!
The huge majority of British police still don't carry guns, and don't wish to. They're probably right. After all, contrast the USA and the UK; in the USA 230 policemen died in the line of duty in 2001, compared to about 70 in Britain in the last 30 years. No wonder 79% of British police are opposed to routinely going armed.
1) If you are contacting me to set up an interview, I assume that you have noticed the fact that I live halfway across the country from your office. Do you understand what a *phone interview* is?
Halfway across the country is nothing, it's only about 100 miles. I suppose you must live in some other country. All the world is not the USA!
3) When you ask me stupid questions like "What are your greatest strengths and weaknesses?" I make a mental note that I will not work for your company.
It's not such a bad question. One of the things one hopes to learn from it, is whether or not the person has a realistic grasp of their own capabilities. If you hire someone who thinks they're better than they really are, they will be frustrated by the low level of tasks they get. Understanding your own weaknesses is also an essential step in the process of becoming better at your job.
5) Please don't spring "tests" and "homework assigments" on me when I show up for an interview.
Worse yet, such things indicate that the employer can't field an interviewer who's able to adequately assess your skills. I never accept job offers from companies who do tests.
9) Where do I see myself in five years? Probably in your job, if this is the most intelligent question you can throw at me.
That question is often appropriate. What you're trying to find out is
Whether the candidate did enough research about the company to understand how they might fit in - if they did, that's a really good sign. If they didn't it's not neccessarily bad though.
If the person has goals. I work for a large consultancy company where people really need to be ambitious. Those who aren't end up with out of date skills and become difficult to place on projects, especially projects on client sites. There is also a link between ambition and ability to work under one's own direction, too. The latter is essential.
Slashdot Mirror
I don't know how advanced Tridge's tools are, but GNU CSSC (downloadable from the the GNU FTP servers) has a certain amount of read-only compatibility with BitKeeper. See also the BitBucket project (code here).
Why bother keeping IA-64? Debian has more alpha users than ia64. There are more SPARC users. Heck, there are even more HPPA users than ia64 users. All the details are available at the Debian Popularity Contest.
The earliest version of Emacs I can lay my hands on dates from 1992. Searching it for occurrences of "(not (eq" reveals lots of hits. One of them (hanoi.el) is from a file last modified in 1987.
So clause 1 of the patent is not novel, and the idea existed widely in the literature and publicly available information at least 18 years before the patent was filed, and quite possibly as much as 42 years.
I think DTrace is available on Linux. It's called DProbes, and was invented by IBM. I have only read the Sun DTrace technical manual the once, but I think there are strong similarities. IBM's DProbes have been around for ages, too - since 2000, according to the ChangeLog, but I didn't hear about it until Richard Moore did a presentation at the UKUUG conference in Manchester in 2001.
I'm no believer in Intelligent Design myself, but I find the arguments of the nerves in the giraffe's neck and other arguments to be more convincing than hairsplitting over "theory" versus "fact".
However, that's not the main reason you're wrong, at least in the context of the large software company where I work (about 20k employees, of whom probably 70% are software professionals). After a one-hour interview (which is shorter than any real interview I've ever done) I would expect to spend at least 45 minutes writing up the result of that interview - deciding whether or not to offer the candidate a role, what role to offer them, how to grade them (essentially, how good they are and what salary to offer). It's even worse for panel interviews because the interviewers also have to discuss the candidate afterwards, which is going to take another 30 minutes or so.
A couple of times I've had to do interviewing full-tilt and for one-on-one interviews the most I've done was probably three or four in a day. Doing more than that means that you have to defer the paperwork until the following day. That's almost always bad because it's essential to keep the candidates straight in your mind when doing the assessment.
Why, you may ask, so much paperwork? Simply put, the candidate has the right (at least in this country) to enquire as to why they were not offered a job. You have to be able to give specific, reasonable and legally justiufiable reasons. Secondly, if you offer them a job and they turn out to be useless or not well suited to their new role, questions will come back to you as to why you hired them. Thirdly, the interview mostly determines the starting salary (along with previous salary and the industry going rates for those types of skills). Therefore it's pretty important to get that right - offer the wrong salary and you won't get the good candidates.
There is a rather better article on the subject of IPV6 adoption at InternetWeek, but that article is now four years old.
As for the specific information in the article,
"IPv6 provides billions more IP addresses" - I think the reporter is a bit confused about all these large numbers. IPv6 provides billions of TIMES more addresses. More even than that in fact; 2 to the power 128 is 79228162514264337593543950336 times greater than 2 to the power 32. (This calculation was brought to you by GNU bc)
"It was created and deployed in response to ... especially as Web use in Asia rises sharply." - The author has fallen for the post hoc ergo propter hoc fallacy. In any case, the beginning of the development of IPv6 occurred significantly before the extensive takeup of Internet technologies in Asia.
As other people have already mentioned (including in the reader comments below the article - I would have contributed but see no point in "registering" with CNET), goodness knows where the journalist got their figure of "257 nodes". They should perhaps take the time to either check their notes or cross-check the information their sources are giving them.
Something the author failed to point out is that it is not only Asian countries that have been working with IPV6. There has been significant piloting in most countries that make use of the Internet. This means that there are IPV6 over IPv4 tunneling facilities that work therse days, meaning that it is not necessary for countries up upgrade everything to IPv6 in order for their businesses to trade with China, no matter what the article implies.
I've found that VueScan (not Free software, but it does work under Linux and there is an edition that costs nothing) gives good results, and the multi-scan feature is especially good. However, there are two problems with using Linux downstream from that point. Firstly, the GIMP doesn't support colour depths greater than 8 bits, while my slide scanner produces 14 bits of colour depth (or 8 if you don't want 14). It's a shame to have to throw away those extra 18 bits of information per pixel.
Having said this, Photoshop Elements has the same limitation, though I'm sure that the premium Photoshop product does not. The Nikon scan tools don't. I use Photoshop Elements but not GIMP. The reaon why is a bit hard to pin down but it comes down to usability. The layering and selection tools in Photoshop Elements are more suited to doing photo manipulation than the ones in GIMP. Also, if you have a complex selection, Photoshop Elements is noticably more responsive on Windows than GIMP is on Linux on the same hardware. GIMP isn't actually sluggish, but PhotoSchop is more responsive and hence certainly easier to use.
I use Linux for exerything else (except a few bits at work) and I wish this wasn't true, but I find that Windows is indeed a better platform for photo work. That's ignoring the whole area of printing, too. Finding a printer that produces high-quality results which works under Linux is easy; finding one that the vendors still sell is much harder. I don't have a lot of time to devote to that search, so I haven't bought a printer yet.
In fact, I wish there were businesses that would sell "Lilnux compatible" hardware. I wouldn't look for support, and I'd pay a premium. I'd just like to be able to buy stuff from someone who can say "I got it to work with Linux".
I think that the best definition of "heavy lifting" is not the size of the installed base or the average number of domains per server, but instead the total number of queries served. Those numbers of course are hard to estimate.
One other difference between the two these days is in the area of non-transferrable copyrights. Of the seven or so distinct copyrights enjoyed (initially) by the author of a work, two cannot be transferred to any other party (even if the author wishes). These are :-
- The right of paternity - that is, the right to be identified as the author of the work
- The right of integrity - the right to object to derogatory treatment of a work (e.g. authors of books can object to adaptations of the book in other forms that they find morally or otherwise offensive)
There's a web page at the Royal College of Music that explains this.Matt Asay, Director of Novell's Linux Business Office, spoke at the recent UK Unix Users' Group Winter conference, as did David Axmark, one of the founders of MySQL AB.
The epicycle manpage also has a HISTORY section which explains a bit about the history of the idea. It says :-
Slashdot being what it is, I'm sure there are readers who have corrections to the above. If you do, please post them as followup or email them to me.
If you need to make an assumption about the classes on which you operate, you can either just perform the operation you need (static compile-time checking will usually cause a compile-time error when the class on which you are operating does not give the requisite guarantee, for example, offer the method you need) or, failing that, you can use the Java language feature which was designed to comminicate interface contracts between classes and their users - that is, use an Interface.