I completely agree. I had the W510, and now have a P50. Both have run Linux perfectly. The only things that may not work (I don't use) are the Screen Color Calibration sensor and the Fingerprint Reader. I got them working on the W510, but never used them, and haven't tried either on the P50.
Work gave me a X1 Carbon 4th Generation, and everything is perfect on it (although, again, haven't tried out the fingerprint reader).
In general, if you can get Atheros or Intel wireless, it should just work out of the box. Those two are the best when it comes to Linux driver support.
Depending on your use case, these are both solid options. I use the P50 for dev work. I chose it because I have 2 2.5" ssds in it (plenty of storage) and 64GB ram (I am constantly compiling android, so outdir in ramdisk saves me hours a day in build time). It can also be configured with 1 2.5" ssd and 2 NVMe/M.2 drives, although the cost of those is still out of my reach.
The X1 on the other hand is great for on the go use. I can usually go a day or two between charges (but I mostly just use it to listen to music and e-mail/ssh into a bigger box to do work).
No, but I bet if in any of those systems you make the same mistake, get called out for it, and make a failed attempt at why your mistake isn't a mistake, or why it's someone else's mistake, you're told to get your shit together (either programatically, or in a box on your way out the door).
All of this 'Linus was mean' hate isn't wrong, it's just not that it wasn't justified. The only time it very quickly escalates to that is when a patch goes in that breaks userspace. You never do that. If you do that, it's going to be reverted if you don't have a fix fast. If you manage to get a really bad driver through a subsystem and into mainline, and later bugs are pointed out, you need to acknowledge it. If you don't acknowledge that you need to fix them and, instead, argue why they aren't bugs/it wasn't a bad design/whatever, you're going to increase the 'bluntness' of it. Enough increases of the bluntness and you get stuff like "This is fucking garbage code, I'm reverting this braindead piece of shit". I don't know that Linus has ever said that, but I know I've seen reverts of code that made me think "Who merged this braindead piece of shit?".
All the times I've submitted patches to subsystems (video, wireless, networking, input), if there was a problem, noone has had a problem pointing it out. Generally it's a list of bullet points for what to fix. Generally, if it takes 2-3 iterations for the submitter to understand what they're doing wrong, the maintainers will start to get pretty specific in what they want to see and why. If in the next iteration you don't fix it, they usually come back with "Not going to review until you fix your FOO". If in the next iteration you don't fix it, it's usually ignored or more strongly worded. I've never once seen someone treated badly on any of the mailing lists on their first submission, nor have I seen a first patch submission utterly destroyed with negativity.
I've seen lots of people screw up and get called out for it, and seen people who tried to deny that they messed up sworn at. Generally, by the time a patch makes it to Linus, it *SHOULD* have been properly verified. If it wasn't, someone screwed up bad. Any bug that makes it all the way through is going to get pretty decent distribution, so it is really important that people do their jobs.
if you get super dexterous with them fingers, you have 2 of each (at least my keyboard reports left and right variants of ctrl/alt/shift, and you have the windows 'super key' and the menu 'super key' that are reported as Super_L and Super_R). That's 256 Combinations per key not flagged as a modifier.
Only if you count nearly every wifi card, graphics card, or cellular radio used in laptops and/or desktops and/or cell phones(or anything that uses a DSP/ASIC of some sort) as a blackbox(I do). After you exclude that list, I'm sure you'll have a massive, massive, list of available options left that are truly 100% blackbox free FOSS experience. Oh yeah, forget that BIOS too.
Linux, Windows, Mac OS, FreeBSD, and other OSes are just user interfaces to a black box full of black boxes. Every device you have to load a firmware to, or give microcode is basically a black box that the OS uses. If you don't have to load firmware to it, and it does a non-trivial task, it probably has the firmware built into it. The only thing the FOSS people want is to know how to give it it's firmware, and tell it to do it's job.
(This is a tongue in cheek reply to the parent, and clarification for the grandparent)
To that point, they already do require that any firmware follow DFS and TPC when operating as an intentional radiator on 5ghz devices (and anything licensed for use in those bands without special licensing/regulation exemptions from them). The issue is, them requiring people do that isn't getting them to do it. Rather than run around slapping $10k fines (pulled from a dark area, no clue what the actual number is) on people who have openwrt running on 5ghz with the TX power set to 1000mw(actual value listed for the 802.11AC radio in my device in openwrt right now) with no DFS/TPC (DFS is not available in the wpad-mini daemon it uses by default), they're trying to make it so that people can't run openwrt. I can't speak to dd-wrt, but I'm guessing it's status is similar.
You can look at it 2 ways: 1, they don't want to potentially ruin a bunch of peoples lives or 2, they don't want to deal with it and are making it someone elses problem. Maybe it's #1 and #2 was the solution they came up with, I don't know, I wasn't on the committee that wrote it.
The unfortunate downside to this is, likely, this will also apply to any cell phone with 5ghz, any laptop/desktop with 5ghz, and a myriad of other devices. The barrier to entry to increasing the TX power on laptops is likely much MUCH lower than getting openwrt onto a router. I remember the old madwifi era windows driver for 802.11g atheros hardware you just had to go to device properties and set the max TX power to whatever you wanted. Later, you could just change that value from the default and edit a registry key.
My belief is the 'correct' answer is to require whatever part of the system handles this to be signed. This works well in cell phones already (the baseband/modem requires that certain parts of the 'radio' firmware partition (it's just a fast 16 image) be signed by the manufacturer or the radio won't turn on). Usually, the signed bit just contains calibration data for the particular RF circuitry, and if you tell it to operate on a band it's calibrated for, it just doesn't do anything. Applying this to routers will allow manufacturers the option of using cheap SOCs like they do now, and have to deal with signing the whole firmware, or have the option of using Fullmac hardware (like they pretty much have to anyways with 802.11ac) and then they can pass the 'signing and securing' buck to the RF manufacturers.
I'm wholly in support of their goal, but not their methodology. With the ever increasing amount of RF enabled devices, we're becoming more and more susceptible to bad neighbors ruining the party. The only upside to the potential to this being passed is, any of your neighbors who are operating their hardware outside it's rated spec will have a hard time when the device eventually cooks itself(if you look at 'high power' 250/500mw wifi cards, they all have great big heat shields on them that get burn you hot when they're operating at high power. The little SOC chip doesn't have that, so running it out of spec shortens it's life).
This reminds me of my dad's 5 rules for life (slightly asciified, and probably from someone before him): ^ That way is up v That was is down All men are assholes All women are crazy Beer is good.
I vaguely recall there being a midi adapter for that so you could do something with a Keyboard (musical type), but it's a really old memory, and I'm too lazy to look it up.
Re:Is XFCE going the bloat-path? What happened to
on
Xfce 4.12 Released
·
· Score: 1
I've always been under the impression that all of the 'bloat' is packaged as additional packages in XFCE. At least in my experience, if you install just the minimum of xfce packages, you get no bloat, but also *SHOCK* are completely lacking in any features beyond the basic window management, task bar, and program launcher.
I have a S4 Mini, it is slightly larger than my Aria was, and around the size of my Old Evo3d. It's about as big as I want to have in my pocket (and not even skinny jeans, just regular old pants). It's an 'old' generation, but I got 4.4.2 working on it fine (yes, I, I did the actual build and released it on Xda), and will eventually get around to getting 5 working on it. It's a dual core snapdragon 1.7ghz with 1.3gb of ram(probably 1gb and something messing with it in my CM rom). I've been happy with it for the year I've had it, and won't upgrade until something else this size comes out.
My only complaint is it's a Spring 'Spark' device, which is tri-band LTE, but doesn't support SVDO/SVLTE (Simultaneous Voice and Data) so when I get a call and I'm tethered, the data drops.
I missed the key point of it being keyboard backlight, lol....
Yes, it is very safe to assume that it's the bios vendor (Lenovo in my case, acer, hp, dell, you name it in the other cases). It boils down to there not being a consistent way to control backlights across laptops.
Actually, with VERY few exceptions, you can run very old userspaces with new kernels. There have been a few 'fixes' that broke old userspaces (by exposing bugs in userspace that weren't triggered pre-fix), but there's a very strict, never break userspace rule. Sometimes you have to set the correct kernel build time options, but it's expected of a person doing that to know what they're doing, or to trust their distro to know what they're doing.
Look at the recent Linux Wireless mailing list... A few weeks ago, the ability to use 'Wireless Extension Compatability' to control wireless was made unselectable. They have been marked deprecated for YEARS(2008), and are now causing problems with supporting newer wifi features. This was very firmly 'NACKED' by Linus, and the wireless tree has to continue supporting an old, broken, way to control wireless devices.
There are also options you can configure in the kernel like 'COMPAT_VDSO' which work around 1 released version of GLIBC (2.3.3), which was also backported to OpenSuse 9.
I know that it may not have been until the 2.6 era that this became truly 'written in stone' law, but it's always been a pretty firm 'rule'. Hence I can still run a.out binaries on my 64bit system. 'ELF' binaries were added around 2.0 (15-20 years ago?), and have been the default since some time between then and now. Still, a.out support will always live on, because you don't break the kernel to userspace abi.
This has been a perpetual problem on my Lenovo W510. In one release, it did multiple steps, in the next one, no backlight control at all. I add some kernel command line options and get a crappy 4 step backlight. In the next release, I have to remove those options because my backlight didn't turn on at all with them. Now no working backlight controls (using the FN+Home/End combo on my laptop keyboard). I poke in the/sys sysfs mount at the backlight control that's registered, and can control the backlight that way. I've been following the ACPI development mailing list and this is a perpetual topic of confrontation.
There are lots of proposed fixes that would just resolve it, but they can't be accepted because they break userspace. The whole problem stems from the Laptop bios. In some cases, the bios will advertise ACPI methods to control the backlight, while the GPU driver exposes the controls as well. Depending on the particular bios version (and sometimes even bios settings), the keypress might, in bios, change the brightness, then report the keypress, or it might report the keypress and depend on the OS to use the ACPI interface to control the backlight, or it might depend on the OS to use the GPU driver interface to control the backlight. On some of the systems, the ACPI interface is sometimes broken, and on some, there are multiple controls (for display port and all the other possible display connections built into the system) with no clear way to determine which one to actually use. Some bioses report to work with 'Windows 2012' but actually completely don't. Some ONLY work with that, but report they work with older ones.
From what I recall of the discussion, Windows 8 deals with this by punting the actual event handling to the GPU drivers, expecting them to know how to handle the hardware.
Similar bugs can be seen in Windows if your run a newer version on hardware designed for a previous version (I saw this running Windows 7 on hardware designed for Windows XP, an old Dell laptop).
I find it kinda crazy that every single other feature of my laptop works perfectly (FIngerprint reader, color calibration, wimax radio {none of which I actually ever use}) while backlight which seems so simple (Press button, change brightness) is in a perpetual state of brokenness.
These 'trivial' changes often cause merge conflicts with other trees. If people are developing against the 'pre change' tree, any changes around the comments might need manual merging. Manual merging introduces additional opportunities for mistakes. I see trivial comment patches like this bounced on these exact grounds in watching active linux driver changes; particularly if you watch a new vendor driver submitted to the staging tree, and then watch it get cleaned up to be in-line with the kernel's coding style.
As far as this PARTICULAR patch being dropped, it probably could have been handled more in line with 'NACK: We'll set a date in the future to do a comment cleaning and have everyone rebase on that', but my first reaction isn't that the developer who declined it is sexist (or whatever the particular flavor of discrimination is). From my PERSONAL Point of view, a change should provide value, and I *PERSONALLY* don't see value in a change like this. A typo fix maybe, but this is not a typo.
The reason I've always heard is pure cost to convert. All the signs, all the cars, everything that uses distances (all the laws would have to be 'amended' to the new units), etc, etc. There is a LOT of infrastructure in the US. It's a physically large country. Even 'phasing' it in is a HUGE undertaking and would take years if not decades to complete.
I am 100% in support of us converting, but I'm glad I don't have to be one of the people that's going to coordinate the madhouse it's going to be when it's finally decided upon and started.
the difference is, it doesn't take the same energy. In the kinetic energy equation, look at the V^2 term. If you start at velocity X, and increase your speed A, your resultant velocity component will be (X + A)^2. Multiplying that out, you get X^2 +2AX + A^2. To go from 0 to 10 mph, you have to add 2 * 10 * 0 + 10 ^ 2 = 100 units (I don't remember the American unit applicable here). To go from 90 to 100, you have to add 2 * 10 * 90 + 10 ^ 2 = 1900 energy units. It takes 19x as much energy to increase speed 10 mph at 90mph IGNORING DRAG.
The X^2 gets ignored because we're only considering the amount of energy we have to ADD to go from X to X + A, and the KE at Vx will end up canceling out the X^2 in the resulting equation subtractions.
Slashdot Mirror
This post contains words known by the state of California to cause cancer.
I completely agree. I had the W510, and now have a P50. Both have run Linux perfectly. The only things that may not work (I don't use) are the Screen Color Calibration sensor and the Fingerprint Reader. I got them working on the W510, but never used them, and haven't tried either on the P50.
Work gave me a X1 Carbon 4th Generation, and everything is perfect on it (although, again, haven't tried out the fingerprint reader).
In general, if you can get Atheros or Intel wireless, it should just work out of the box. Those two are the best when it comes to Linux driver support.
Depending on your use case, these are both solid options. I use the P50 for dev work. I chose it because I have 2 2.5" ssds in it (plenty of storage) and 64GB ram (I am constantly compiling android, so outdir in ramdisk saves me hours a day in build time). It can also be configured with 1 2.5" ssd and 2 NVMe/M.2 drives, although the cost of those is still out of my reach.
The X1 on the other hand is great for on the go use. I can usually go a day or two between charges (but I mostly just use it to listen to music and e-mail/ssh into a bigger box to do work).
No, but I bet if in any of those systems you make the same mistake, get called out for it, and make a failed attempt at why your mistake isn't a mistake, or why it's someone else's mistake, you're told to get your shit together (either programatically, or in a box on your way out the door).
All of this 'Linus was mean' hate isn't wrong, it's just not that it wasn't justified. The only time it very quickly escalates to that is when a patch goes in that breaks userspace. You never do that. If you do that, it's going to be reverted if you don't have a fix fast. If you manage to get a really bad driver through a subsystem and into mainline, and later bugs are pointed out, you need to acknowledge it. If you don't acknowledge that you need to fix them and, instead, argue why they aren't bugs/it wasn't a bad design/whatever, you're going to increase the 'bluntness' of it. Enough increases of the bluntness and you get stuff like "This is fucking garbage code, I'm reverting this braindead piece of shit". I don't know that Linus has ever said that, but I know I've seen reverts of code that made me think "Who merged this braindead piece of shit?".
All the times I've submitted patches to subsystems (video, wireless, networking, input), if there was a problem, noone has had a problem pointing it out. Generally it's a list of bullet points for what to fix. Generally, if it takes 2-3 iterations for the submitter to understand what they're doing wrong, the maintainers will start to get pretty specific in what they want to see and why. If in the next iteration you don't fix it, they usually come back with "Not going to review until you fix your FOO". If in the next iteration you don't fix it, it's usually ignored or more strongly worded. I've never once seen someone treated badly on any of the mailing lists on their first submission, nor have I seen a first patch submission utterly destroyed with negativity.
I've seen lots of people screw up and get called out for it, and seen people who tried to deny that they messed up sworn at. Generally, by the time a patch makes it to Linus, it *SHOULD* have been properly verified. If it wasn't, someone screwed up bad. Any bug that makes it all the way through is going to get pretty decent distribution, so it is really important that people do their jobs.
if you get super dexterous with them fingers, you have 2 of each (at least my keyboard reports left and right variants of ctrl/alt/shift, and you have the windows 'super key' and the menu 'super key' that are reported as Super_L and Super_R). That's 256 Combinations per key not flagged as a modifier.
Only if you count nearly every wifi card, graphics card, or cellular radio used in laptops and/or desktops and/or cell phones(or anything that uses a DSP/ASIC of some sort) as a blackbox(I do). After you exclude that list, I'm sure you'll have a massive, massive, list of available options left that are truly 100% blackbox free FOSS experience. Oh yeah, forget that BIOS too.
Linux, Windows, Mac OS, FreeBSD, and other OSes are just user interfaces to a black box full of black boxes. Every device you have to load a firmware to, or give microcode is basically a black box that the OS uses. If you don't have to load firmware to it, and it does a non-trivial task, it probably has the firmware built into it. The only thing the FOSS people want is to know how to give it it's firmware, and tell it to do it's job.
(This is a tongue in cheek reply to the parent, and clarification for the grandparent)
To that point, they already do require that any firmware follow DFS and TPC when operating as an intentional radiator on 5ghz devices (and anything licensed for use in those bands without special licensing/regulation exemptions from them). The issue is, them requiring people do that isn't getting them to do it. Rather than run around slapping $10k fines (pulled from a dark area, no clue what the actual number is) on people who have openwrt running on 5ghz with the TX power set to 1000mw(actual value listed for the 802.11AC radio in my device in openwrt right now) with no DFS/TPC (DFS is not available in the wpad-mini daemon it uses by default), they're trying to make it so that people can't run openwrt. I can't speak to dd-wrt, but I'm guessing it's status is similar.
You can look at it 2 ways: 1, they don't want to potentially ruin a bunch of peoples lives or 2, they don't want to deal with it and are making it someone elses problem. Maybe it's #1 and #2 was the solution they came up with, I don't know, I wasn't on the committee that wrote it.
The unfortunate downside to this is, likely, this will also apply to any cell phone with 5ghz, any laptop/desktop with 5ghz, and a myriad of other devices. The barrier to entry to increasing the TX power on laptops is likely much MUCH lower than getting openwrt onto a router. I remember the old madwifi era windows driver for 802.11g atheros hardware you just had to go to device properties and set the max TX power to whatever you wanted. Later, you could just change that value from the default and edit a registry key.
My belief is the 'correct' answer is to require whatever part of the system handles this to be signed. This works well in cell phones already (the baseband/modem requires that certain parts of the 'radio' firmware partition (it's just a fast 16 image) be signed by the manufacturer or the radio won't turn on). Usually, the signed bit just contains calibration data for the particular RF circuitry, and if you tell it to operate on a band it's calibrated for, it just doesn't do anything. Applying this to routers will allow manufacturers the option of using cheap SOCs like they do now, and have to deal with signing the whole firmware, or have the option of using Fullmac hardware (like they pretty much have to anyways with 802.11ac) and then they can pass the 'signing and securing' buck to the RF manufacturers.
I'm wholly in support of their goal, but not their methodology. With the ever increasing amount of RF enabled devices, we're becoming more and more susceptible to bad neighbors ruining the party. The only upside to the potential to this being passed is, any of your neighbors who are operating their hardware outside it's rated spec will have a hard time when the device eventually cooks itself(if you look at 'high power' 250/500mw wifi cards, they all have great big heat shields on them that get burn you hot when they're operating at high power. The little SOC chip doesn't have that, so running it out of spec shortens it's life).
This reminds me of my dad's 5 rules for life (slightly asciified, and probably from someone before him):
^ That way is up
v That was is down
All men are assholes
All women are crazy
Beer is good.
I vaguely recall there being a midi adapter for that so you could do something with a Keyboard (musical type), but it's a really old memory, and I'm too lazy to look it up.
I've always been under the impression that all of the 'bloat' is packaged as additional packages in XFCE. At least in my experience, if you install just the minimum of xfce packages, you get no bloat, but also *SHOCK* are completely lacking in any features beyond the basic window management, task bar, and program launcher.
I have a S4 Mini, it is slightly larger than my Aria was, and around the size of my Old Evo3d. It's about as big as I want to have in my pocket (and not even skinny jeans, just regular old pants). It's an 'old' generation, but I got 4.4.2 working on it fine (yes, I, I did the actual build and released it on Xda), and will eventually get around to getting 5 working on it. It's a dual core snapdragon 1.7ghz with 1.3gb of ram(probably 1gb and something messing with it in my CM rom). I've been happy with it for the year I've had it, and won't upgrade until something else this size comes out.
My only complaint is it's a Spring 'Spark' device, which is tri-band LTE, but doesn't support SVDO/SVLTE (Simultaneous Voice and Data) so when I get a call and I'm tethered, the data drops.
I was just thinking he was applying the Unix mentality to his life. Do one thing, but do it well.
I missed the key point of it being keyboard backlight, lol....
Yes, it is very safe to assume that it's the bios vendor (Lenovo in my case, acer, hp, dell, you name it in the other cases). It boils down to there not being a consistent way to control backlights across laptops.
Actually, with VERY few exceptions, you can run very old userspaces with new kernels. There have been a few 'fixes' that broke old userspaces (by exposing bugs in userspace that weren't triggered pre-fix), but there's a very strict, never break userspace rule. Sometimes you have to set the correct kernel build time options, but it's expected of a person doing that to know what they're doing, or to trust their distro to know what they're doing.
Look at the recent Linux Wireless mailing list... A few weeks ago, the ability to use 'Wireless Extension Compatability' to control wireless was made unselectable. They have been marked deprecated for YEARS(2008), and are now causing problems with supporting newer wifi features. This was very firmly 'NACKED' by Linus, and the wireless tree has to continue supporting an old, broken, way to control wireless devices.
There are also options you can configure in the kernel like 'COMPAT_VDSO' which work around 1 released version of GLIBC (2.3.3), which was also backported to OpenSuse 9.
I know that it may not have been until the 2.6 era that this became truly 'written in stone' law, but it's always been a pretty firm 'rule'. Hence I can still run a.out binaries on my 64bit system. 'ELF' binaries were added around 2.0 (15-20 years ago?), and have been the default since some time between then and now. Still, a.out support will always live on, because you don't break the kernel to userspace abi.
This has been a perpetual problem on my Lenovo W510. In one release, it did multiple steps, in the next one, no backlight control at all. I add some kernel command line options and get a crappy 4 step backlight. In the next release, I have to remove those options because my backlight didn't turn on at all with them. Now no working backlight controls (using the FN+Home/End combo on my laptop keyboard). I poke in the /sys sysfs mount at the backlight control that's registered, and can control the backlight that way. I've been following the ACPI development mailing list and this is a perpetual topic of confrontation.
There are lots of proposed fixes that would just resolve it, but they can't be accepted because they break userspace. The whole problem stems from the Laptop bios. In some cases, the bios will advertise ACPI methods to control the backlight, while the GPU driver exposes the controls as well. Depending on the particular bios version (and sometimes even bios settings), the keypress might, in bios, change the brightness, then report the keypress, or it might report the keypress and depend on the OS to use the ACPI interface to control the backlight, or it might depend on the OS to use the GPU driver interface to control the backlight. On some of the systems, the ACPI interface is sometimes broken, and on some, there are multiple controls (for display port and all the other possible display connections built into the system) with no clear way to determine which one to actually use. Some bioses report to work with 'Windows 2012' but actually completely don't. Some ONLY work with that, but report they work with older ones.
From what I recall of the discussion, Windows 8 deals with this by punting the actual event handling to the GPU drivers, expecting them to know how to handle the hardware.
Similar bugs can be seen in Windows if your run a newer version on hardware designed for a previous version (I saw this running Windows 7 on hardware designed for Windows XP, an old Dell laptop).
I find it kinda crazy that every single other feature of my laptop works perfectly (FIngerprint reader, color calibration, wimax radio {none of which I actually ever use}) while backlight which seems so simple (Press button, change brightness) is in a perpetual state of brokenness.
Don't you mean Darth Vader?
These 'trivial' changes often cause merge conflicts with other trees. If people are developing against the 'pre change' tree, any changes around the comments might need manual merging. Manual merging introduces additional opportunities for mistakes. I see trivial comment patches like this bounced on these exact grounds in watching active linux driver changes; particularly if you watch a new vendor driver submitted to the staging tree, and then watch it get cleaned up to be in-line with the kernel's coding style.
As far as this PARTICULAR patch being dropped, it probably could have been handled more in line with 'NACK: We'll set a date in the future to do a comment cleaning and have everyone rebase on that', but my first reaction isn't that the developer who declined it is sexist (or whatever the particular flavor of discrimination is). From my PERSONAL Point of view, a change should provide value, and I *PERSONALLY* don't see value in a change like this. A typo fix maybe, but this is not a typo.
This is why I always pee in the shower. Problem solved!
The reason I've always heard is pure cost to convert. All the signs, all the cars, everything that uses distances (all the laws would have to be 'amended' to the new units), etc, etc. There is a LOT of infrastructure in the US. It's a physically large country. Even 'phasing' it in is a HUGE undertaking and would take years if not decades to complete.
I am 100% in support of us converting, but I'm glad I don't have to be one of the people that's going to coordinate the madhouse it's going to be when it's finally decided upon and started.
the difference is, it doesn't take the same energy. In the kinetic energy equation, look at the V^2 term. If you start at velocity X, and increase your speed A, your resultant velocity component will be (X + A)^2. Multiplying that out, you get X^2 +2AX + A^2. To go from 0 to 10 mph, you have to add 2 * 10 * 0 + 10 ^ 2 = 100 units (I don't remember the American unit applicable here). To go from 90 to 100, you have to add 2 * 10 * 90 + 10 ^ 2 = 1900 energy units. It takes 19x as much energy to increase speed 10 mph at 90mph IGNORING DRAG.
The X^2 gets ignored because we're only considering the amount of energy we have to ADD to go from X to X + A, and the KE at Vx will end up canceling out the X^2 in the resulting equation subtractions.
Win 7 works great on Qemu (and also in Xen, and Virtualbox) on an i7 820qm with 1 core dedicated to it as well as 2gb of ram set aside for it.
a twitter reader?
yacc, I do believe
Nope, isn't 59 prime?
Me, the IT ninja
haha, forgot about this picture from the party at leopold bros.