I don't care what the number itself is, but I think it's useful to
note it's normal operating temperature number, and the high range of
numbers so I can see when it's getting too high.
Well, I don't have the thermal design reference in front of me at the moment (but I actually read it back when I was curious) but basically the numbers are just a delta to an arbitrary calibrated point (which is not even published) which represents the point where the fan needs to be spinning full speed. Get too much beyond that, and the thing will just shut down anyway. So the only way you should ever get a too-high readout is if the cutoff circuit and/or sensor is malfunctioning in the first place - kind of a chicken and egg problem.
The above applies to the new-style sensors. The old style sensors (which appear to be still present) appear to be even less useful.
me realy liked the guys who mounted the cpu to a aloy chimney. nice concept. The chimney effect almost makes coolers unneeded...
mounted inside a PC case made of transparent plexiglas.
Transparent aluminum... duh!
> And at last why not using Subversion?!
Subversion is not a distributed version control system. It makes it very difficult for 3rd parties to take the Android platform and build products on top of it. With Subversion, or any other non-distributed version control system, non-committers are 2nd class citizens who don't have the same level of functionality as the blessed committers/maintainers of the project.
We very much want to make Android available for everyone to use, extend, and build on top of. Open source allows rapid innovation to occur, and to open up markets that didn't exist before. Distributed version control tools are the next great thing for open source, as it ensures these innovators are really free to access the code, modify it, and redistribute those modifications.
I think this is one of the best explanations of the advantages of git i've heard so far.
noncomitters may be second class citizens, but why can't they commit to a branch?
I won't say more before I try git.
Everybody sings its praises, it must be just that wonderful.
Fleeb said something the other day though.
He was working on something and committing it on his local laptop so when he got back to the office he could sync and yada yada yada.
I don't know abuot the rest of you, but one of the big reasons I use version control at all is to get a copy of the source off my machine which I generally don't trust for more than 10 minutes at a time.
I'm not a big fan of losing work.
ford, your local git copy contains _ALL_ information of the repository.
you can do blame or log without connecting to the server, your local working copy contains all the data.
plus, a SVN workingcopy is _BIGGER_ than a Git workingcopy.
On the branching/forking thing...
GIT doesn't have linear revisions. you can commit to your local copy and start some weird vodoo not everybody might like plus stay synced with the main development tree.
You can work on something until its ready to be committed upstream. Or you could add features, which upstream doesn't like without having to worry that new features / bugfixes upstream does won't fix in easily. Git also offers upstream a very compfortable way to accept and integrate patches from "forkers"; Think of the problems the linux kernel has; git takes care of them and aids the maintainers without being in the way.
git to svn is like what one might think of 3d to 2d.
as long as you're in 2d you might find everything easy to use and live with, once you come to know 3d you don't want to miss it anymore...
Everybody raves about git. That doesn't make it good or useful for my purposes, it just means everybody raves about it.
Everybody raves about windows, doesn't make it good, os/2 was superior
Telling git that I specifically want to commit something, as opposed to letting it figure it out seems a bit of a drag to me. Obviously to other people so they added the -a flag.
But again, I find value in having the repository be elsewhere, so by making my localdisk the repository of all versioning information (by default, I know it can sync else where, I haven't gotten to that yet) this seems less useful to me than cvs or svn.
What I liked a lot was that you can say switch to branch, and it just does. you can do that in cvs and you can't do that in svn and it drives me nuts.
you have to differentiate between 'commit', 'pull' and 'push' afaik. the later sync with your raid5 DLT backuped s00per save server.
(no I'm no git master yet)
and... NT4 definitely was superior to OS/2. I've worked with it, and coded for it. It definitely was no fun.
OTOh, os/2 just was another proprietary system, which basicaly shared the general closed source problem windows nt4 had and still has too.
for some fancy reason, there even is an adon to git: st-git which seems to be good for stopping to work on patch a, pull patch b from the stack, work on that... and commit.
Wed Feb 17 2010 11:06:12 PM EST from LoanShark @ Uncensoredmounted inside a PC case made of transparent plexiglas.
Transparent aluminum... duh!
Not just an obscure geek reference to a Star Trek movie.
and... NT4 definitely was superior to OS/2. I've worked with it, and
coded for it. It definitely was no fun.
I realize you're just baiting me, but I haven't had this flamewar in a long time, let's see how rusty my os/2 has gotten.
Explain to me any meaningful way in which ny4 was superior to os/2.
os/2 separated the gui layer from the kernel layer. some would say this makes nt superior because it's faster, but from a 'right way to do things' os/2 did it the better way.
you'll also notice no gui in the linux kernel.
That was just a warm up. bring it on boy.
Transparent aluminium is transient.
I thought NT4 separated the two layers as well.
You perceive that they're mixed, though, because various gui-related function calls are found within the kernel.dll... which isn't really the kernel, per se, but something that seems to do many things that you'd want to do with a kernel (by making those calls to the kernel for you).
I can't speak as much about OS/2, although I always liked that OS better.
I just had to deal with NT-derived OSes far more, and learned a bit about it while working with some code related to device drivers for the OS.