My biggest gripe with Dia itself nowdays is the lack of support for text labels on objects (I am looking at.95 currently shipping with Debian which is one version back from the leading edge). As a result something that should be a more or less point-n-click operation ends up being done in 3-4 steps: object, text, group, etc). Even that does not work for arrows and relations where the label has to be clearly associated with the arrow and render with it. As a result making a good looking network diagram or data flow diagram is all but impossible (labels do not stick nicely to the links).
As far as lack of integration it is openoffice fault for not caring for vector graphics (dunno how is it as far as API is concerned).
If it accessing the onboard TPM this is quite likely. I cann bet that they smacked a few global locks around those accesses just in case to ensure that a silly race condition in the access will not allow someone to break through the precious DRM. PC TPMs are disgustingly slow so every access leads to a fairly long period when interrupts are not being serviced. As a result the system capability to process interrupts drastically decreases whenever the DRM subsystem has been activated. Add to that some priority to multimedia and the picture will be exactly as observed.
This is all hypothetical of course, but it more or less makes sense. I would not be surprised if that is the case.
Strace relies on a kernel interface which cannot be disabled by Joe Average Luser. I have not used ltrace, but in order to do what it does it has to rely on library preloads and other userspace approaches. That is trivial to detect. Even less paranoid closed source application will pick it up and refuse to run.
It has no other legtimate means of getting your GECOS. As a result, I would expect it to do a/etc/passwd read via the getpw family of calls during initial registration. Doing it later on is not strictly necessary, but not very "nefarious" either.
Dunno about AppArmour, but there is no way in hell to distinguish between legitimate getpwnam, getpwuid, etc calls and reading the whole passwd file on a linux system using strace.
Example:
strace on ls -laF immediately gives
open("/etc/passwd", O_RDONLY) = 4
Followed by quite a few reads out of it. So by the logic of the poster ls -laF is a horrible application doing horrible things to your system.
Unless you have read the source or single-stepped trhough the app with a debugger, examined the data and found that it does something nefarious like sending skype the whole of your/etc/passwd you should not claim that it does something illegitimate.
All of these are not that bad already. Granted they can be better, but it is a case of diminishing returns. To make them better you have to invest a lot for a little return. Also, as Linux is used more and more in embedded devices serving this purpose many of them will improve anyway without throwing effort at it.
Also, IMO Linux actually does the job for an average desktop more or less all right already. I am judging by the number of complaints I get from my significant half which is a Mac user when using any of the machines at home. They have been diminishing towards 0 lately.
Where Linux/OSS sucks royally is business use. There are plenty of areas there which will deliver Linux to a bigger audience with much less investment than any of the UI improvements and support for fancy hardware which linux supports better then windows anyway. The last 3 pieces of really obscure hardware I threw it at it just worked.
Linux/OSS needs good diagram drawing program support including basic visio import/export (without the executable extensions and VB integration). Dia has significantly improved over the years and it currently approaches Visio as far as features. Some of course are fundamentally different like python integration instead of VB integration, etc. It is still way behind visio on ease of use for the basic UI (when it comes to advanced stuff they both suck bricks through a thin straw sidewise). Also, dia integration into openoffice is inexistent. What made visio the de-facto corporate diagram standard is the integration into office. Dia has none. It does not even have a suitable export which can be imported into openoffice as vector graphics. While at it - openoffice support for internal graphics drawn using impress and/or writer. These leave a lot to be desired as well.
OSS needs good client-server project manager. There is no need to go for a standalone UI project management software (it is not the route everyone else in the market is is going anyway). Server-client does best for things like this. There is a number of hacked together serverside projects which are desperately asking for a non-Web or Ajax UI. Here OSS can also jump straight ahead of the MSFT in the game if it integrates it to issue tracking and CRM where OSS is way ahead of the game (MSFT still does not have it and is least likely to).
Contact management integration and contact management in all PIM apps must improve before Joe Average can use it. At the moment most of linux PIM has finally reached some form of useable state and linux itself can sync to most devices like phones and PDAs (if everything else fails Bluetooth usually works). Still, setting it up and getting it going is often outright painful. There are also annoying glitches all over the place.
Correct timezone processing in calendaring applications must improve. Both Evolution and Sunbird suck at this royally. One forward or import export and the TZ of your calendar gets completely and utterly screwed. Granted MSFT has this f*** up as well so OSS apps are not alone here (dunno when will the developers learn to use universal time for all time storage).
Tickets per day is an idiotic measure of productivity for a sysadmin. It is a helpdesk metric, not a sysadmin metric.
If you have designed and built a good system and all of your maintenance and upgrades are preemptive, not reactive you should have 0 tickets and answer 0 tickets. Unfortunately using the classic ticket metric this means that you are scratching your testicles and doing 0 work.
So for a sysadmin (especially on the server side) the inverse of the tickets filed per day +1 (to avoid div by 0) on a scale of 0 to 1 is probably the best metric. If all systems are up and running you have 1 (perfect). If you get a ticket your score drops to 0.5, 2 tickets - 0.3 and so on.
Sorry, too high blood level in the caffeine subsystem when posting the GP. I was in absolute agreement. IRC must die.
As far as Jabber vs IRC vs the rest of the IM I agree they all suck and they can all be used for zombie control. You can write a BOT that logs in on yahoo, AIM or anything else you like. I used to have a Yahoo Messenger BOT that talked to a MON alert system and pinged me when something went apeshit in the network (you could also get network status and such). Writing it was quite trivial, unfortunately Yahoo changed the protocol and the underlying perl modules stopped working. Modifying that code for zombie control would have been trivial as well.
The difference IRC makes is:
1. Its tradition. It has been the stomping ground of 1337 wankers since the mid-90es. Gives cred to socially deficient people.
2. Ability for the user to gain some level of administrative control over a chatroom (aka channel) and exercise it to exclude everyone else from it so it can use it for its own nefarious purposes.
By the way, as far IM of any form is concerned it is also yesterdays day tech for BOTs. Newer ones build peer-to-peer networks and encrypt them. As a result finding the command and control center becomes practically impossible.
In my case the attacker did not leave the rootkit on the system. We never managed to find it.
We found a couple of backdoors now and then none of which was particularly fancy. For example sendmail had an extra command added which executed a shell, etc. So I suspect that he loaded the rootkit straight into memory over the network after accessing the compromised machine through the backdoor. As a result it was never present for forensics.
The most unpleasant bit was that he nuked the machine at the slightest suspicion of being observed.
Nope your honour. Java is actually one of the biggest factors behind Sun still being a server power. If it was not for java Sun would have been dead long ago.
One java app starts at least 64 threads at the server by default. Most apps use even higher defaults and admins push this number to at least 256 for most server installations. This type of load runs best on guess what - Sun (or Azul where Sun now has a good size stake).
While Sun UltraSparc servers may suck bricks through a thin straw sidewise on raw CPU performance, the number of cores Sun puts in a single box makes them better at running java apps than anything else the industry has to offer. This has been the case for a while now and with the rollout of next generation Rock based servers it will become even more so. Add to that the inherent advantage Java has on Big Endian machines as a big endian language and the picture is complete.
While you can run java on anything, if your business depends on the performance at which you run it you usually end up running it on Sun hardware.
In the USA in theory as much as they like. AFAIK unlocking phones and supplying tools for that is a legal business activity in the USA. In practice with the iPhone it will be the first time an unlock business meets a top-to-bottom PKI which can be claimed to be a measure to protect copyright including content. I will be extremely surprised if Apple has not designed it deliberately to allow the use of DMCA to override the legality of phone unlocking. It will be interesting to watch this one.
Correct. Always pull the plug out of the wall the moment you suspect that something is wrong. This is what I meant when I said - take it offline (my fault, should have written it better). If it is compromised the data on it is worthless anyway and you need to go back to backups so the loss of data from pulling the plug is trully in the "who cares" area.
All of these will help only if it is cracked by amateur sr1pt k1dd10tz like in this case. If it is cracked properly you will not see anything or spook off the intruder. He will either go underground or destroy the box with all of your data (not that you should try to use it as it may have been altered).
I have seen a number of rootkits for Linux as far back as 97-98 which were considerably more advanced. It was a bit of an arms race between the admins (including me) and the guys who were breaking in. By the end the best rootkits could:
1. Load a whole hidden fs with tools into a ramdisk or hidden area on the filesystem not visible using normal tools. 2. Hide all sockets, processes and files belonging to the rootkit completely. You simply could no longer see them using netstat, ps and other similar tools. 3. Monitor network driver state for the promisc flag and "scrub" backdoor traffic out of it so it is no longer visible using tcpdump and ethereal. 4. Adjust memory totals and df so that you do not see them. This was also the only way we found to catch it. Try to allocate 95% of the remaining free memory and see the system oops magestically. 5. Doctor logs so that you could not notice anything. 6. The rootkit itself handled all connections via something that looked like ssh. I never managed to figure out how it loaded. One of the executables in the system loaded at startup was backdoored. Probably sendmail or one of the other daemons it could not do without. 7. The rootkit managed to masq changed files completely. Tripwire and md5sums were reporting all OK while executables were being changed.
That was a the tech level in 97. I would expect 10 years later a good rootkit to be even better. Looking at the blog post I can only laugh.
If you suspect a system is cracked:
1. Take it offline and take the disks out. Analyse the system completely offline looking at the disk from another system mounted as ro (on SCSI discs use the RO jumper). Never ever even try to start it. Nowdays knoppix is a great help. Most importantly - do not fsck systems before mounting as the rootkit may hide in orphaned areas which fsck will fix.
2. If you are monitoring traffic, monitor it on a switch span port or create yourself a simple multiple interface box which serves as a firewalling bridge (so you can hijack the more interesting bits and alter them). Lex Book PCs are a good choice as they can run either Linux or BSD and are as portable as a laptop. A recent Via with 2 Ethernet ports is also a good choice as it can handle up to 1GB of traffic across as a bridge.
The world has changed dramatically since the mid 80-es. In the mid-80es the world was a world of national telco monopolies. French traffic stayed in France not traversing a single US fibre. German traffic stayed in Germany and so on. If you wanted to tap a conversation you had to get down and dirty and tap it locally. And most importantly the spooks had to do this themselves. Backdooring ATT switches did not really give them anything as far as Alcatel switches in France or the Marconi ones in the UK were concerned.
That is no longer the case. Nowdays a packet from a point A to a point B outside USA has a fair chance of passing across at least several pieces of USA owned infrastructure that are not on USA soil. USA telecommunication companies operate franchises and services all over the world. One of the conditions to do so is that they are regulated under the local legislation. Local legislation in most of the world explicitly prohibit such shit and so far US companies have usually stayed clear from such activities.
What Mr McConnell wants is essentially to give himself a free reign regarding forcing them to engage in surveillance for him globally and for purposes completely different from fighting terrorism. Just read the first 2 paragraphs from his interview and add to that the rabid insistence of this USA administration that USA laws apply to a USA corp or cittizen regardless of where it is.
This is a very different ball game compared to the 80-es and frankly this is likely to backfire very badly.
Who cares about the ATT trial. RTFA for f*** sake.
There in the first paragraphs he basically states that his primary objective when he came in was to make any communication between foreign parties handled by an American entity and passing via an American wire or fibre a fair game with no judicial oversight for purposes of foreign intelligence including one for purely economical purposes. Nothing to do with terrorism or domestic surveillance. Terrorism comes much later as an excuse.
Now add to that the particular insistence of this administration that an American person or corporation has to comply with American laws anywhere around the world and what does this mean from the perspective of "using american communications" and you get the real picture of what is this all about. It is not surprising that while they got lucky via judge-shopping the first time they got stopped the second time.
Mind posting some links?
As all I can see a presoldered shipped together with the motherboard as an EPIA solution.
The official Via specs say BGA by the way which means it is soldred.
By what I recall - no, but I have not looked at the OpenSSH latest and greatest (it has been 6+ months since I looked at this).
The reason is that at least as of the versions present in major distros openssh does not for some reason support openssl engines. AES (and RSA in latest Via CPUs) is done using an openssl engine which has to be initialised and loaded. This can be done for OpenVPN, Apache, Pound and nearly any other piece of software using OpenSSL, but not OpenSSH. For some reason Theo's people in their infinite wisdom left that part out (it is trivial). There was a patch, dunno if it has made it into the main tree.
As far as non-OpenSSL software is concerned, the kernel itself can use the hardware AES for filesystems and IPSEC. I have run it for quite a while for both OpenVPN and IPSEC. It can run around a Dual Xeon in circles. I would expect it to have the same killer performance for encryption of filesystems and encrypted backups as well. In fact this is possibly the only CPU on the market at the moment where having all of your data encrypted is a realistic proposition. The rest will choke on it and crawl like a 486.
There is also further improvement from having true on-CPU hardware RNG which all programs in need of good random numbers can use as it is implemented at kernel level.
Probably the highest praise to it is the fact that most of these features have now started showing up on Intel roadmap documents for the future x86 CPUs destined for the embedded market. It is the Athlon history repeating. When someone else is doing something right Intel copies it, claims innovation and launches a marketing salvo trying to lie that "they have been doing it all along".
Why not. If you are running an Intel Centrino or Core laptop you most likely having less most of the time.
Centrino as well as any Core derived notebook under Winhoze uses voltage and frequency scaling. It will ramp up to its spec-ed frequency only when pushed really hard and in some laptops only when on AC power. If you want to actually have reasonable battery performance on Linux you end up doing the same using the cpufreq susbsystem. Example from a Core Duo on which I am typing this post:
model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping : 6 cpu MHz : 229.167
Note the actual CPU frequency above (this is using ondemand kernel governor). It is more than twice less than 500.
I have used every single Via CPU from the original Eden 533 up to 1.5GHz C7 and IMO the C3-C5 spec Edens are just about useful for a dedicated appliances, small firewalls, small specialised servers and such. They do not have enough grunt for a laptop. The fact that most of them have are shipped bundled with relatively weak video does not really help either. Even the mpeg support on some motherboards cannot really help. Xterm is probably the most you can do with them as far as clients are concerned. Still better than similarly clocked Crusoe though (now that is a drag of all drags).
C7 is a completely different beast. This is probably the best CPU for a corporate laptop out there at the moment. A laptop is worthless without a "link to the mothership". Intel Core and AMD have to use CPU resource to do all of the encryption and decryption. This may amount to 30-40% of your CPU on a 54G wireless lan. Compared to that Via C7 has hardware AES acceleration so you can actually protect your traffic properly while using less than 1% of your CPU. It also has enough grunt to run most common road warrior apps at acceptable speeds. It is a pity it is not available as a laptop choice anywhere outside the far east.
AFAIK all of the Via CPUs are designed to be soldered onto a motherboard.
AFAIK Buswise they used to be compatible with 370. The original Eden 533 and 800 6 years back were actually available in 370 form to be used as a CPU upgrade. There was virtually 0 interest to this form factor and Via dropped it in favour of integrated MB + CPU and soldering the CPU onto the board.
I suspect that you can probably have it done in a socket 370 form. I do not see the point though as most motherboards will not be able to provide the correct voltages and most BIOSes will not have any support for it.
It will be the same as with the International War Crime court. When USA does not like an international law in their favour they go around and get themselves exempted from it on a per-country basis. If this will really happen, they will simply make sure that there is no market for AllOfMP3 Mark 2 or any other similar outfit. They will pressure all countries with large potential customer markets not to trade with Antigua.
This will not give Antigua a chance to recoup its losses or pressure the USA into fixing the relevant part of the Sharia law passed by the council of elders on Capitol Hill.
Slashdot Mirror
My biggest gripe with Dia itself nowdays is the lack of support for text labels on objects (I am looking at .95 currently shipping with Debian which is one version back from the leading edge). As a result something that should be a more or less point-n-click operation ends up being done in 3-4 steps: object, text, group, etc). Even that does not work for arrows and relations where the label has to be clearly associated with the arrow and render with it. As a result making a good looking network diagram or data flow diagram is all but impossible (labels do not stick nicely to the links).
As far as lack of integration it is openoffice fault for not caring for vector graphics (dunno how is it as far as API is concerned).
Good thinking.
If it accessing the onboard TPM this is quite likely. I cann bet that they smacked a few global locks around those accesses just in case to ensure that a silly race condition in the access will not allow someone to break through the precious DRM. PC TPMs are disgustingly slow so every access leads to a fairly long period when interrupts are not being serviced. As a result the system capability to process interrupts drastically decreases whenever the DRM subsystem has been activated. Add to that some priority to multimedia and the picture will be exactly as observed.
This is all hypothetical of course, but it more or less makes sense. I would not be surprised if that is the case.
Strace relies on a kernel interface which cannot be disabled by Joe Average Luser. I have not used ltrace, but in order to do what it does it has to rely on library preloads and other userspace approaches. That is trivial to detect. Even less paranoid closed source application will pick it up and refuse to run.
It has no other legtimate means of getting your GECOS. As a result, I would expect it to do a /etc/passwd read via the getpw family of calls during initial registration. Doing it later on is not strictly necessary, but not very "nefarious" either.
Dunno about AppArmour, but there is no way in hell to distinguish between legitimate getpwnam, getpwuid, etc calls and reading the whole passwd file on a linux system using strace.
/etc/passwd you should not claim that it does something illegitimate.
Example:
strace on ls -laF immediately gives
open("/etc/passwd", O_RDONLY) = 4
Followed by quite a few reads out of it. So by the logic of the poster ls -laF is a horrible application doing horrible things to your system.
Unless you have read the source or single-stepped trhough the app with a debugger, examined the data and found that it does something nefarious like sending skype the whole of your
The cartoon is quite tame. Just compare to some recent Spanish ones involving their royal family ...
All of these are not that bad already. Granted they can be better, but it is a case of diminishing returns. To make them better you have to invest a lot for a little return. Also, as Linux is used more and more in embedded devices serving this purpose many of them will improve anyway without throwing effort at it.
Also, IMO Linux actually does the job for an average desktop more or less all right already. I am judging by the number of complaints I get from my significant half which is a Mac user when using any of the machines at home. They have been diminishing towards 0 lately.
Where Linux/OSS sucks royally is business use. There are plenty of areas there which will deliver Linux to a bigger audience with much less investment than any of the UI improvements and support for fancy hardware which linux supports better then windows anyway. The last 3 pieces of really obscure hardware I threw it at it just worked.
Any one of these will
Tickets per day is an idiotic measure of productivity for a sysadmin. It is a helpdesk metric, not a sysadmin metric.
If you have designed and built a good system and all of your maintenance and upgrades are preemptive, not reactive you should have 0 tickets and answer 0 tickets. Unfortunately using the classic ticket metric this means that you are scratching your testicles and doing 0 work.
So for a sysadmin (especially on the server side) the inverse of the tickets filed per day +1 (to avoid div by 0) on a scale of 0 to 1 is probably the best metric. If all systems are up and running you have 1 (perfect). If you get a ticket your score drops to 0.5, 2 tickets - 0.3 and so on.
Sorry, too high blood level in the caffeine subsystem when posting the GP. I was in absolute agreement. IRC must die.
As far as Jabber vs IRC vs the rest of the IM I agree they all suck and they can all be used for zombie control. You can write a BOT that logs in on yahoo, AIM or anything else you like. I used to have a Yahoo Messenger BOT that talked to a MON alert system and pinged me when something went apeshit in the network (you could also get network status and such). Writing it was quite trivial, unfortunately Yahoo changed the protocol and the underlying perl modules stopped working. Modifying that code for zombie control would have been trivial as well.
The difference IRC makes is:
1. Its tradition. It has been the stomping ground of 1337 wankers since the mid-90es. Gives cred to socially deficient people.
2. Ability for the user to gain some level of administrative control over a chatroom (aka channel) and exercise it to exclude everyone else from it so it can use it for its own nefarious purposes.
By the way, as far IM of any form is concerned it is also yesterdays day tech for BOTs. Newer ones build peer-to-peer networks and encrypt them. As a result finding the command and control center becomes practically impossible.
Couldn't agree less. IRC must die. If you need a chat server for work you can always run jabber.
In my case the attacker did not leave the rootkit on the system. We never managed to find it.
We found a couple of backdoors now and then none of which was particularly fancy. For example sendmail had an extra command added which executed a shell, etc. So I suspect that he loaded the rootkit straight into memory over the network after accessing the compromised machine through the backdoor. As a result it was never present for forensics.
The most unpleasant bit was that he nuked the machine at the slightest suspicion of being observed.
Nope your honour. Java is actually one of the biggest factors behind Sun still being a server power. If it was not for java Sun would have been dead long ago.
One java app starts at least 64 threads at the server by default. Most apps use even higher defaults and admins push this number to at least 256 for most server installations. This type of load runs best on guess what - Sun (or Azul where Sun now has a good size stake).
While Sun UltraSparc servers may suck bricks through a thin straw sidewise on raw CPU performance, the number of cores Sun puts in a single box makes them better at running java apps than anything else the industry has to offer. This has been the case for a while now and with the rollout of next generation Rock based servers it will become even more so. Add to that the inherent advantage Java has on Big Endian machines as a big endian language and the picture is complete.
While you can run java on anything, if your business depends on the performance at which you run it you usually end up running it on Sun hardware.
C'mon not Florida marriage vs hurricane jokes all over again.
In the USA in theory as much as they like. AFAIK unlocking phones and supplying tools for that is a legal business activity in the USA. In practice with the iPhone it will be the first time an unlock business meets a top-to-bottom PKI which can be claimed to be a measure to protect copyright including content. I will be extremely surprised if Apple has not designed it deliberately to allow the use of DMCA to override the legality of phone unlocking. It will be interesting to watch this one.
Correct. Always pull the plug out of the wall the moment you suspect that something is wrong. This is what I meant when I said - take it offline (my fault, should have written it better). If it is compromised the data on it is worthless anyway and you need to go back to backups so the loss of data from pulling the plug is trully in the "who cares" area.
All of these will help only if it is cracked by amateur sr1pt k1dd10tz like in this case. If it is cracked properly you will not see anything or spook off the intruder. He will either go underground or destroy the box with all of your data (not that you should try to use it as it may have been altered).
I have seen a number of rootkits for Linux as far back as 97-98 which were considerably more advanced. It was a bit of an arms race between the admins (including me) and the guys who were breaking in. By the end the best rootkits could:
1. Load a whole hidden fs with tools into a ramdisk or hidden area on the filesystem not visible using normal tools.
2. Hide all sockets, processes and files belonging to the rootkit completely. You simply could no longer see them using netstat, ps and other similar tools.
3. Monitor network driver state for the promisc flag and "scrub" backdoor traffic out of it so it is no longer visible using tcpdump and ethereal.
4. Adjust memory totals and df so that you do not see them. This was also the only way we found to catch it. Try to allocate 95% of the remaining free memory and see the system oops magestically.
5. Doctor logs so that you could not notice anything.
6. The rootkit itself handled all connections via something that looked like ssh. I never managed to figure out how it loaded. One of the executables in the system loaded at startup was backdoored. Probably sendmail or one of the other daemons it could not do without.
7. The rootkit managed to masq changed files completely. Tripwire and md5sums were reporting all OK while executables were being changed.
That was a the tech level in 97. I would expect 10 years later a good rootkit to be even better. Looking at the blog post I can only laugh.
If you suspect a system is cracked:
1. Take it offline and take the disks out. Analyse the system completely offline looking at the disk from another system mounted as ro (on SCSI discs use the RO jumper). Never ever even try to start it. Nowdays knoppix is a great help. Most importantly - do not fsck systems before mounting as the rootkit may hide in orphaned areas which fsck will fix.
2. If you are monitoring traffic, monitor it on a switch span port or create yourself a simple multiple interface box which serves as a firewalling bridge (so you can hijack the more interesting bits and alter them). Lex Book PCs are a good choice as they can run either Linux or BSD and are as portable as a laptop. A recent Via with 2 Ethernet ports is also a good choice as it can handle up to 1GB of traffic across as a bridge.
Not quite so.
The world has changed dramatically since the mid 80-es. In the mid-80es the world was a world of national telco monopolies. French traffic stayed in France not traversing a single US fibre. German traffic stayed in Germany and so on. If you wanted to tap a conversation you had to get down and dirty and tap it locally. And most importantly the spooks had to do this themselves. Backdooring ATT switches did not really give them anything as far as Alcatel switches in France or the Marconi ones in the UK were concerned.
That is no longer the case. Nowdays a packet from a point A to a point B outside USA has a fair chance of passing across at least several pieces of USA owned infrastructure that are not on USA soil. USA telecommunication companies operate franchises and services all over the world. One of the conditions to do so is that they are regulated under the local legislation. Local legislation in most of the world explicitly prohibit such shit and so far US companies have usually stayed clear from such activities.
What Mr McConnell wants is essentially to give himself a free reign regarding forcing them to engage in surveillance for him globally and for purposes completely different from fighting terrorism. Just read the first 2 paragraphs from his interview and add to that the rabid insistence of this USA administration that USA laws apply to a USA corp or cittizen regardless of where it is.
This is a very different ball game compared to the 80-es and frankly this is likely to backfire very badly.
Who cares about the ATT trial. RTFA for f*** sake.
There in the first paragraphs he basically states that his primary objective when he came in was to make any communication between foreign parties handled by an American entity and passing via an American wire or fibre a fair game with no judicial oversight for purposes of foreign intelligence including one for purely economical purposes. Nothing to do with terrorism or domestic surveillance. Terrorism comes much later as an excuse.
Now add to that the particular insistence of this administration that an American person or corporation has to comply with American laws anywhere around the world and what does this mean from the perspective of "using american communications" and you get the real picture of what is this all about. It is not surprising that while they got lucky via judge-shopping the first time they got stopped the second time.
Mind posting some links? As all I can see a presoldered shipped together with the motherboard as an EPIA solution. The official Via specs say BGA by the way which means it is soldred.
Quite likely. Though not per W. AFAIK even at 229MHz core is in the 10W+ area.
By what I recall - no, but I have not looked at the OpenSSH latest and greatest (it has been 6+ months since I looked at this).
The reason is that at least as of the versions present in major distros openssh does not for some reason support openssl engines. AES (and RSA in latest Via CPUs) is done using an openssl engine which has to be initialised and loaded. This can be done for OpenVPN, Apache, Pound and nearly any other piece of software using OpenSSL, but not OpenSSH. For some reason Theo's people in their infinite wisdom left that part out (it is trivial). There was a patch, dunno if it has made it into the main tree.
As far as non-OpenSSL software is concerned, the kernel itself can use the hardware AES for filesystems and IPSEC. I have run it for quite a while for both OpenVPN and IPSEC. It can run around a Dual Xeon in circles. I would expect it to have the same killer performance for encryption of filesystems and encrypted backups as well. In fact this is possibly the only CPU on the market at the moment where having all of your data encrypted is a realistic proposition. The rest will choke on it and crawl like a 486.
There is also further improvement from having true on-CPU hardware RNG which all programs in need of good random numbers can use as it is implemented at kernel level.
Probably the highest praise to it is the fact that most of these features have now started showing up on Intel roadmap documents for the future x86 CPUs destined for the embedded market. It is the Athlon history repeating. When someone else is doing something right Intel copies it, claims innovation and launches a marketing salvo trying to lie that "they have been doing it all along".
Why not. If you are running an Intel Centrino or Core laptop you most likely having less most of the time.
Centrino as well as any Core derived notebook under Winhoze uses voltage and frequency scaling. It will ramp up to its spec-ed frequency only when pushed really hard and in some laptops only when on AC power. If you want to actually have reasonable battery performance on Linux you end up doing the same using the cpufreq susbsystem. Example from a Core Duo on which I am typing this post:
model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz
stepping : 6
cpu MHz : 229.167
Note the actual CPU frequency above (this is using ondemand kernel governor). It is more than twice less than 500.
Not really.
I have used every single Via CPU from the original Eden 533 up to 1.5GHz C7 and IMO the C3-C5 spec Edens are just about useful for a dedicated appliances, small firewalls, small specialised servers and such. They do not have enough grunt for a laptop. The fact that most of them have are shipped bundled with relatively weak video does not really help either. Even the mpeg support on some motherboards cannot really help. Xterm is probably the most you can do with them as far as clients are concerned. Still better than similarly clocked Crusoe though (now that is a drag of all drags).
C7 is a completely different beast. This is probably the best CPU for a corporate laptop out there at the moment. A laptop is worthless without a "link to the mothership". Intel Core and AMD have to use CPU resource to do all of the encryption and decryption. This may amount to 30-40% of your CPU on a 54G wireless lan. Compared to that Via C7 has hardware AES acceleration so you can actually protect your traffic properly while using less than 1% of your CPU. It also has enough grunt to run most common road warrior apps at acceptable speeds. It is a pity it is not available as a laptop choice anywhere outside the far east.
AFAIK all of the Via CPUs are designed to be soldered onto a motherboard.
AFAIK Buswise they used to be compatible with 370. The original Eden 533 and 800 6 years back were actually available in 370 form to be used as a CPU upgrade. There was virtually 0 interest to this form factor and Via dropped it in favour of integrated MB + CPU and soldering the CPU onto the board.
I suspect that you can probably have it done in a socket 370 form. I do not see the point though as most motherboards will not be able to provide the correct voltages and most BIOSes will not have any support for it.
Nope it is not.
It will be the same as with the International War Crime court. When USA does not like an international law in their favour they go around and get themselves exempted from it on a per-country basis. If this will really happen, they will simply make sure that there is no market for AllOfMP3 Mark 2 or any other similar outfit. They will pressure all countries with large potential customer markets not to trade with Antigua.
This will not give Antigua a chance to recoup its losses or pressure the USA into fixing the relevant part of the Sharia law passed by the council of elders on Capitol Hill.