The parent meant "replies". He's asking about having a stage lighting fixture report back when it has finished moving to the position.
DMX equipment is starting to implement that now. It's an enhancement to DMX called Remote Device Management. It's backward compatible with older DMX fixtures, but not older splitters. RDM allows two kinds of communication from fixtures to the controller. First, discovery. Rather than programming in all of your fixtures, your controller can query "which fixtures are available?" and automatically load the profiles for those models of fixture. Secondly, the controller can send a data request to the fixture and the fixture can respond. So "are you done moving to the new position yet?", "Yes I am.". Fixtures can't initiate communication of their own accord because there is only one data line, and the controller is sending on that line until it relinquishes the line to a fixture.
> Further, I'd argue that I doubt most cloud storage companies list "disk storage" as their primary expense
40TB drives would mean the cloud providers need 90% fewer servers. A tenth as many servers means the datacenter can be 1/10th the size. 90% fewer servers means 90% less tech time of employees going around swapping out bad drives, running cables to new servers, etc. Basically ALL the costs other than marketing and internet bandwidth are a function of the number of drives.
Looking at it another way, if a provider is currently using 4TB drives, switching to 40TB would mean they could have 10 times as many customers in the same datacenter, on the same servers, for the same cost. So yes, most of their costs are directly proportional to how many disks they have spinning.
> I'd similarly argue that even if being able to quadruple storage capacities per 3.5" bay did save them a bunch of money, that they would be unlikely to pass that cost along to customers.
There is in fact competition in the cloud storage market. A lot of competition. So much competition that until recently, major companies were willing to lose money on every customer in order to get more customers (they planned to start making money after the fast growth of the industry began to slow). Cloud storage companies absolutely are busting their ass to give customers the best service they can at the lowest price. They want the business, so they're offering the lowest price they can.
Amazon is of course the premium brand in the space. What they offer their customers is being the *best*, not the *cheapest*. Amazon's cloud has so many useful features added now that the documentation is well over a thousand pages. They give customers "the best bang for the buck" by constantly adding more bang, for the same buck. To that end, Amazon is spending over a billion dollars a month on R&D to constantly improve their products.
Larger drives means fewer servers per terabyte. Fewer servers means all costs drop. The dollar cost of the bare drives themselves is a fairly small portion of the overall costs, so *cheaper* drives don't make a huge difference, but *bigger* drives make a big difference.
Rsync can do pretty much whatever you want regarding symlinks. There are three different command line options. Since symlinks may point outside of the directory you're copying, and may be either relative paths or absolute paths, the "right" behavior is situation dependent. Rsync lets you choose what is right for your situation.
A sensor that outputs a PWM signal, or something that accepts it (such as a servo) has a specified allowable range and curve that it COULD use, and an actual range that it DOES use.
Servo controllers nominally output pulses between 1ms (zero position) and 2ms (full rotation). Actual servo models don't exactly conform to this "standard", so you tune your control to the specific model of servo.
Analogously, the DMX protocol standard says that the BREAK is signaled by a pulse of AT LEAST 88 microseconds (and up to one second). Many controllers fail to read the spec carefully try to output exactly 88 microseconds, sometimes falling a bit short. If you program your DMX to work according to the standard, and test it with truly conforming peers, it'll fail to work with the many DMX items that don't quite conform, or are borderline, sometimes falling a couple microseconds short. To have compatibility with "almost compliant" neighbors, DMX outputs can output a 92 microsecond break, and receivers can accept a 84 microsecond break.
I suspect that's what happened here. The third-party parts ALMOST matched the Apple parts. Maybe they were barely complaint to the spec while the Apple parts were well within spec, or maybe the third-party parts were almost compliant. Either way, they didn't work quite the same, so customers saw failures. Apple adjusted it to work within the parameters of the third-party parts.
I highly suspect if you tested MAF sensor or O2 sensor speced with an output range of "up to 0-5V", you'd find some model's actual range is 0.2-4.5V, while another model's actual range might be 0.3-4.7V. Firmware tuned for the first, the OEM model, wouldn't work quite work as well with the second one - even though they both have "0-5V output".
I tried to include a few words in my post to hint I wasn't saying that Fortran was the FIRST high-level language, or necessarily the first practical one, or the maybe the first widely used high level language. It was an example of an early high-level language that was part of a revolution in the field. C compilers weren't the first to do any optimization, and SQL wasn't the first declarative language. As you said, modern C compilers rewrite the code in ways that would have been unimaginable in Fortran's heyday.
> > With C, we got optimizing compilers that totally rewrite the specification
> We didn't.
Technically, we did. With this paycheck, I got gas. I got gas. With my last paycheck, I also got gas. With my paycheck a year ago, I got gas. Still it's true that "with this paycheck, I got gas";)
Am I being pedantic? Of course. That's my job. I'm a programmer. Ccompiler->provides_optimizer == true.
> the humans are no longer coders, they will instead be writing specifications for the code
Humans wrote computer code until 1957. In 1957, it became possible to instead write a specification for what the code should DO, writing that specification in a language called Fortran. Then the Fortran compiler wrote the actual machine code.
In 1972 or thereabouts, another high-level specification language came out, called C. With C, we got optimizing compilers that totally rewrite the specification, doing things in a different order, entirely skipping steps that don't end up affecting the result, etc. The optimizing C compiler (ex gcc) writes machine code that ends up with the same result as the specification, but may get there in a totally different way.
In the late 1970s, a new kind of specification language came out. Instead of the programmer saying "generate code to do this, then that, then this", with declarative programming the programming simply specifies the end result:. "All the values must be changed to their inverse", or "output the mean, median, and maximum salary". These are specifications you can declare using the SQL language. We also use declarative specifications to say "all level one headings should end up centered on the page" or "end up with however many thumbnails in each row as will fit". We use CSS to declare these specifications. The systems then figure out the intermediate code and machine code to make that happen.
The future you suggest has been here for 60 years. Most programmers don't write executable machine code and haven't for many years. We write specifications for the compilers, interpreters, and query optimizers that then generate code that's used to generate code which is interpreted by microcode which is run by the CPU.
Heck, since the mid-1970s it hasn't even been NECESSARY for humans to write the compilers. Specify a language and yacc will generate a compiler for it.
A lot of people worry about being replaced by machines. That's been a concern for a significant portion of the population, since at least the 1600s. What actually gets tossed aside and replaced by a new machine, every few years, is old machines. Yet machines never worry about being replaced. Indeed they don't worry about anything, or have any concept of self at all. Let me know when machines start worrying about being replaced by Machine 2.0 and that's when I'll be worried.
> Not sure what this has to do with the environmental cost in heat of Google's activities.
Well if you're concerned about the environmental impact of generating heat (a reasonable concern), would it not be useful to be able to measure and compare the amount of heat generated? Rather than the obvious approach of measuring heat by temperature rise email etc, is it not simpler to remember that heat out = energy in?
Endothermic reactions always result in products less stable than the reactants. That's why they are endothermic. That heat is being stored in bonds where it will later (potentially much later) be released in an exothermic reaction.
The only reasons I can think of, based on the older version I've used, is if you have your own reasons to avoid Android, or you want to run Ubuntu or Debian userland on your phone.
Android seems to do fine on phones - it works well enough that most devices sold in the last few years are Android phones. Obviously some people would prefer an alternative, other than Apple iOS.
> Is there a viable pocket-sized, battery-powered server that one could carry in order to use "a terminal and a web browser" with a Chromebook?
It's Linux. A terminal is the native interface. What makes it a Chromebook is that rather than a standard server-side install of Linux (no GUI) or standard desktop install (lots of GUI shit I don't use anyway), it has a web browser a couple other things in a small, very efficient GUI. No GUI for partitioning hard drives, no pre-installed solitaire game. Which is fine for me, I don't partition drives in a GUI anyway.
Then you asked if browsing the web works without an internet connection? Huh? No, I don't do a lot of web browsing work without WiFi.
If you want to, you can install as much as you want of the Ubuntu or Debian userland on top of the ChromeOS-provided kernel. I've not seen any need. My work as a programmer / hacker basically uses a text editor in the terminal, ssh, and a browser.
People who have never tried a Chromebook like to say things like "they are for dummies who don't know anything about computers. A power user would never use one.". One guy I've spoken to, whom I consider to be a power user, had this to say about his new Chromebook:
"suspect I'll make this my primary laptop. I tend to like my laptops slightly smaller, but I think I can lug around this 1.5kg monster"
Maybe someone thinks that guy, Linus Torvalds, is a newbie, and doesn't understand the needs of power users like themselves. Okay, fine, lug around something that weighs three times as much and takes six times longer to boot if you want. Linus and I can look at kernel patches on our Chromebooks.
The Chromebook works far better for me if there is any appreciable amount of typing involved. Sure, you CAN put a tablet in a case with a little keyboard, but it's not made for that, and it shows. It doesn't sit comfortably in your lap as you type away like the laptop / Chromebook form factor does.
Chromebooks also tend to have much longer battery life.
I mostly use a large Android phone if I'm not working. I couldn't very well do much work on my phone. On a Chromebook I can (mostly I work in a terminal and a web browser). There is definitely a place for a Chromebook. Most of what I do, for work and play, I can do just fine on a Chromebook. The one thing that comes to mind it doesn't work well for is using Microsoft SQL Server Studio.
> So they tried something, and it didn't work out for them.
They tried mobile and failed and tried again and failed again and tried again and failed again for 21 years before giving up.
Why have they kept trying to get into mobile? Because most computing devices sold today are mobile, the market for corded computers has been falling for several years, and is expected to continue to fall.
> The vast overwhelming majority of all PCs sold at retail come with Windows on them.
In 2011, 365 million PCs were sold. In 2015, 288 million. In 2016, 269 million. When your market is dropping 8% per year, that's not good. It's also not good for Microsoft that the percentage of PCs sold with Linux pre-installed increases every year. They are doing okay today - 269 million is a lot less than 365 million, but it's still a lot of computers. Have a look at what that curve looks like 10 years from now, though, as sales keep dropping 10% each year. There's a reason Microsoft is trying to sell Linux on the cloud - it's because they see the curve, they know they won't keep selling Windows on PCs.
Heck, they've stopped even TRYING to sell new versions of Windows, upgrades. In the 1990s people lined up around the block to pay $200 for the latest Windows upgrade. Now nobody buys a new Windows version, literally nobody at all.
> "Running Windows 7 disables or restricts these features:"
They don't know what all features in various updates may not work, and they don't want to figure that out for an officially obselete operating system. One thing that often may not work is booting. Installing from a OEM disk probably won't work because it won't have the drivers for a USB3 keyboard and mouse. Power management will often not work - once the machine goes to sleep, it may not wake up again.
APPLICATION code generally is tied to a specific instruction set and OS. Application code doesn't generally care about the hardware, because the operating system takes care of the hardware. On the other hand, the operating system DOES care about the hardware, and Skylake hardware is different. Skylake is NOT "Ivy Bridge, faster" - it's a different microarchitecture.
> USB3 worked before, it will work after (the USB2 specification has not changed, for example).
Windows 7 does not support USB3 out of the box. USB2 is not USB3. They have one thing in common - similar names. USB2 is a synchronous, half duplex protocol over one pair of wires. USB3 is an asynchronous, full duplex protocol with three pairs.
> Microsoft tried, people preferred to choose between the OSes that are more popular. Mozilla tried Firefox OS, but that didn't work out either. BlackBerry's BBOS also couldn't find enough takers
> Do you think some company, or individual, should attempt to create their own mobile operating system?
Lots of people and companies DID try. Big companies and small.
> Ideally, the market is more consumer friendly when there are more than one or two dominant forces.
Apparently not in this instance, in which consumers are served by having a wide range of apps to choose from, on a wide range of hardware. Android offers hardware from $50 to $1,500, with millions of apps. Apparently that's what consumers want. They could have chosen Windows Mobile, or Firefox OS, or Blackberry, or several others. They prefer the well-known platforms with millions of apps and a wide choice of hardware.
There IS a third player - Samsung. Samsung's phones are "Android based" in the same way that Android is "Linux based".
> "Microsoft shares have doubled since he took the top job in early 2014" > And so has almost every other share.
Not by a long shot.
The Dow was at about 17,000 in early 2014. It's now a bit below 23. Nasdaq went from 4,300 to 6,600. Microsoft went from $38 to $76. So Microsoft has significantly outperformed other companies generally.
Compare Microsoft to the other leaders of the PC industry from 2014. The top three PC makers in 2014 were Lenovo, Dell, and HP. Lenovo has last half it's value. Dell went private to deal with "significant issues", and HP Inc dropped from $29 to $20.
>. But if Windows 7 is truly incompatible with Skylake CPUs, then doesn't that mean the Skylake CPU is not compatible with x64?
Applications written on / for Windows 7 should work on Skylake. The operating system needs to be concerned with more than just the instruction set. The OS has to support the busses in use (NVME and USB3), the power management scheme, the boot process (UEFI, not BIOS), hardware interrupts, etc. A few manufacturers have tested some of their Skylake models with Windows 7.
It goes both ways. A manufacturer isn't going to release a new high-power CPU that can't run any operating system. The CPU needs to "support" (be compatible with) some operating system, and the company making the CPU will likely need to be involved with the first OS port.
The case of AMD64, aka x64, is a good example. Before the CPU was actually produced, AMD made a emulator, then AMD and Suse ported Linux to the new instruction set. By actually running Linux on the new instruction set they could identify any problems with the CPU design design before making it in actual silicon.
Four years later, Microsoft released some x64 support in Windows. So you could say that first the hardware CPU was manufactured to support 64-bit Linux, which existed before the CPU was produced. Years later, Windows started supporting the CPU. Similarly, back in 1995, Linux added support for 64 Alpha processors, which existed before Linux supported them.
You are absolutely correct for SHA-1 hashes of random data, of significant length. Passwords, however, are neither random nor long. I'll describe the attack for you and you can try it out yourself. The fact that an ordinary consumer PC can compute SHA-1 password hashes at the rate 10 billion per second is why SHA-1 is no longer appropriate for passwords. Here's how the attack is done:
Download two large lists of passwords, any "combined list" from your favorite haxor site will do. It doesn't matter what sites the passwords are from. If you run a comparison, you'll find that given two lists of a million passwords, about half of the passwords will be on both lists - with different accounts. That is, there is about a 50/50 chance that your password is in the list because somebody else used the same password. You probably know it's not too hard to find lists totaling many millions of passwords (we don't need fresh ones). If we put together a list of 10 million passwords, most of the Disqus passwords will be on our list, because SOMEBODY used the same password (not necessarily the same person).
So we take the first, most common password on our list of previously seen passwords and try it against each of the 17 million hashes from Disqus. Because SHA-1 is so fast, our $100 GPU can check all 17 million hashes in one millisecond. In one second, we can try the top thousand most common passwords. In 24 hours, we can test out 10 MILLION passwords that somebody, somewhere, has used before, and thereby crack perhaps 8 million of the Disqus passwords - which gives us the email addresses to match those passwords.
For passwords, therefore, you need a hash that can't be easily computed at the rate of billions per second with commodity hardware. Bcrypt and scrypt are appropriate choices. To avoid certain problems with particularly long or particularly short passwords, you first take a SHA-2 hash of the password, then scrypt it.*
* In the general case of random data, hashing a hash doesn't add security. Passwords, however are not the general case.
> Also, I'm not sure about your reasoning on thrust being nearly proportional to blade length.
By Newton's third law, thrust is equal to the force applied to the air moved through the rotor disc. That's the area of the rotor disc times the average acceleration of the air (average velocity change). There are two terms there, disc area and AVERAGE Delta V of the air.
The disc area is proportional to the square of the rotor radius. On the other hand, the portion of the rotor near the hub has nearly zero linear velocity, and flows very little air. The majority of the thrust is generated nearer the rotor tips. The area of high thrust, say within 8 feet of the rotor tip, is essentially the circumference of the disc, and therefore linearly proportional to the rotor diameter.
So one term is linearly proportional to the rotor radius, one term to the square of the radius.
>. The big reason most helicopters have one rotor is simplicity in design, maintenance, and control.
A single 40 foot rotor has 4 times the disc area of two 20 foot rotors. Because thrust is the disc area multiplied by the average delta V, four times as much swept area makes a big difference in thrust. The one large rotor makes much more thrust than two rotors of half the diameter.
For fixed-wing craft (airplanes) blade tips CAN as you say, go supersonic, though that's quite rare because there is an enormous increase in drag at transonic speeds. Helicopters not only have the large increase in drag to worry about, but also in forward flight one wing is moving forward while the other wing in moving backward.
Consider the world's fastest military helicopter, the Chinook, flying forward at 315km/h. If the blade tip were moving at 1,000 km/h relative to the fuselage, the advancing blade would be moving through the air at 1,315, or Mach 1.1, while the retreating blade on the other side would have airspeed of 685 km/h. That would mean the advancing side of the rotor would be going twice as fast as the retreating side. You can imagine how it's pretty much impossible to design a rotor that can be moving at both supersonic speeds and very subsonic at the same time.
Additionally the blade tips at times enter the vortex of the other blade, which will cause local transonic flow, and disruption of the aerodynamics, if the "normal" velocity is even close to the speed of sound.
Practical designs for regular use are therefore limited to well under the speed of sound at the tips. This is no great loss because rotor drag is a function of the CUBE of the speed. While lift increases with the square of diameter, drag increases with the cube, so a large, slow rotor is better anyway.
Slashdot Mirror
The parent meant "replies". He's asking about having a stage lighting fixture report back when it has finished moving to the position.
DMX equipment is starting to implement that now. It's an enhancement to DMX called Remote Device Management. It's backward compatible with older DMX fixtures, but not older splitters. RDM allows two kinds of communication from fixtures to the controller. First, discovery. Rather than programming in all of your fixtures, your controller can query "which fixtures are available?" and automatically load the profiles for those models of fixture. Secondly, the controller can send a data request to the fixture and the fixture can respond. So "are you done moving to the new position yet?", "Yes I am.". Fixtures can't initiate communication of their own accord because there is only one data line, and the controller is sending on that line until it relinquishes the line to a fixture.
> Further, I'd argue that I doubt most cloud storage companies list "disk storage" as their primary expense
40TB drives would mean the cloud providers need 90% fewer servers. A tenth as many servers means the datacenter can be 1/10th the size. 90% fewer servers means 90% less tech time of employees going around swapping out bad drives, running cables to new servers, etc. Basically ALL the costs other than marketing and internet bandwidth are a function of the number of drives.
Looking at it another way, if a provider is currently using 4TB drives, switching to 40TB would mean they could have 10 times as many customers in the same datacenter, on the same servers, for the same cost. So yes, most of their costs are directly proportional to how many disks they have spinning.
> I'd similarly argue that even if being able to quadruple storage capacities per 3.5" bay did save them a bunch of money, that they would be unlikely to pass that cost along to customers.
There is in fact competition in the cloud storage market. A lot of competition. So much competition that until recently, major companies were willing to lose money on every customer in order to get more customers (they planned to start making money after the fast growth of the industry began to slow). Cloud storage companies absolutely are busting their ass to give customers the best service they can at the lowest price. They want the business, so they're offering the lowest price they can.
Amazon is of course the premium brand in the space. What they offer their customers is being the *best*, not the *cheapest*. Amazon's cloud has so many useful features added now that the documentation is well over a thousand pages. They give customers "the best bang for the buck" by constantly adding more bang, for the same buck. To that end, Amazon is spending over a billion dollars a month on R&D to constantly improve their products.
Larger drives means fewer servers per terabyte. Fewer servers means all costs drop. The dollar cost of the bare drives themselves is a fairly small portion of the overall costs, so *cheaper* drives don't make a huge difference, but *bigger* drives make a big difference.
Rsync can do pretty much whatever you want regarding symlinks. There are three different command line options. Since symlinks may point outside of the directory you're copying, and may be either relative paths or absolute paths, the "right" behavior is situation dependent. Rsync lets you choose what is right for your situation.
A sensor that outputs a PWM signal, or something that accepts it (such as a servo) has a specified allowable range and curve that it COULD use, and an actual range that it DOES use.
Servo controllers nominally output pulses between 1ms (zero position) and 2ms (full rotation). Actual servo models don't exactly conform to this "standard", so you tune your control to the specific model of servo.
Analogously, the DMX protocol standard says that the BREAK is signaled by a pulse of AT LEAST 88 microseconds (and up to one second). Many controllers fail to read the spec carefully try to output exactly 88 microseconds, sometimes falling a bit short. If you program your DMX to work according to the standard, and test it with truly conforming peers, it'll fail to work with the many DMX items that don't quite conform, or are borderline, sometimes falling a couple microseconds short. To have compatibility with "almost compliant" neighbors, DMX outputs can output a 92 microsecond break, and receivers can accept a 84 microsecond break.
I suspect that's what happened here. The third-party parts ALMOST matched the Apple parts. Maybe they were barely complaint to the spec while the Apple parts were well within spec, or maybe the third-party parts were almost compliant. Either way, they didn't work quite the same, so customers saw failures. Apple adjusted it to work within the parameters of the third-party parts.
I highly suspect if you tested MAF sensor or O2 sensor speced with an output range of "up to 0-5V", you'd find some model's actual range is 0.2-4.5V, while another model's actual range might be 0.3-4.7V. Firmware tuned for the first, the OEM model, wouldn't work quite work as well with the second one - even though they both have "0-5V output".
Thanks for that interesting bit of information.
I tried to include a few words in my post to hint I wasn't saying that Fortran was the FIRST high-level language, or necessarily the first practical one, or the maybe the first widely used high level language. It was an example of an early high-level language that was part of a revolution in the field. C compilers weren't the first to do any optimization, and SQL wasn't the first declarative language. As you said, modern C compilers rewrite the code in ways that would have been unimaginable in Fortran's heyday.
> > With C, we got optimizing compilers that totally rewrite the specification
> We didn't.
Technically, we did. With this paycheck, I got gas. I got gas. With my last paycheck, I also got gas. With my paycheck a year ago, I got gas. Still it's true that "with this paycheck, I got gas" ;)
Am I being pedantic? Of course. That's my job. I'm a programmer. Ccompiler->provides_optimizer == true.
> the humans are no longer coders, they will instead be writing specifications for the code
Humans wrote computer code until 1957. In 1957, it became possible to instead write a specification for what the code should DO, writing that specification in a language called Fortran. Then the Fortran compiler wrote the actual machine code.
In 1972 or thereabouts, another high-level specification language came out, called C. With C, we got optimizing compilers that totally rewrite the specification, doing things in a different order, entirely skipping steps that don't end up affecting the result, etc. The optimizing C compiler (ex gcc) writes machine code that ends up with the same result as the specification, but may get there in a totally different way.
In the late 1970s, a new kind of specification language came out. Instead of the programmer saying "generate code to do this, then that, then this", with declarative programming the programming simply specifies the end result:. "All the values must be changed to their inverse", or "output the mean, median, and maximum salary". These are specifications you can declare using the SQL language. We also use declarative specifications to say "all level one headings should end up centered on the page" or "end up with however many thumbnails in each row as will fit". We use CSS to declare these specifications. The systems then figure out the intermediate code and machine code to make that happen.
The future you suggest has been here for 60 years. Most programmers don't write executable machine code and haven't for many years. We write specifications for the compilers, interpreters, and query optimizers that then generate code that's used to generate code which is interpreted by microcode which is run by the CPU.
Heck, since the mid-1970s it hasn't even been NECESSARY for humans to write the compilers. Specify a language and yacc will generate a compiler for it.
A lot of people worry about being replaced by machines. That's been a concern for a significant portion of the population, since at least the 1600s. What actually gets tossed aside and replaced by a new machine, every few years, is old machines. Yet machines never worry about being replaced. Indeed they don't worry about anything, or have any concept of self at all. Let me know when machines start worrying about being replaced by Machine 2.0 and that's when I'll be worried.
> Not sure what this has to do with the environmental cost in heat of Google's activities.
Well if you're concerned about the environmental impact of generating heat (a reasonable concern), would it not be useful to be able to measure and compare the amount of heat generated? Rather than the obvious approach of measuring heat by temperature rise email etc, is it not simpler to remember that heat out = energy in?
Endothermic reactions always result in products less stable than the reactants. That's why they are endothermic. That heat is being stored in bonds where it will later (potentially much later) be released in an exothermic reaction.
The only reasons I can think of, based on the older version I've used, is if you have your own reasons to avoid Android, or you want to run Ubuntu or Debian userland on your phone.
Android seems to do fine on phones - it works well enough that most devices sold in the last few years are Android phones. Obviously some people would prefer an alternative, other than Apple iOS.
In fact, 100% of all energy used by anyone ends up as heat.
All that solar and wind energy - it ends up being converted to heat. All of it.
Okay, so if you use the energy to lift something up, it doesn't turn to heat until the thing comes back down.
> Is there a viable pocket-sized, battery-powered server that one could carry in order to use "a terminal and a web browser" with a Chromebook?
It's Linux. A terminal is the native interface. What makes it a Chromebook is that rather than a standard server-side install of Linux (no GUI) or standard desktop install (lots of GUI shit I don't use anyway), it has a web browser a couple other things in a small, very efficient GUI. No GUI for partitioning hard drives, no pre-installed solitaire game. Which is fine for me, I don't partition drives in a GUI anyway.
Then you asked if browsing the web works without an internet connection? Huh? No, I don't do a lot of web browsing work without WiFi.
If you want to, you can install as much as you want of the Ubuntu or Debian userland on top of the ChromeOS-provided kernel. I've not seen any need. My work as a programmer / hacker basically uses a text editor in the terminal, ssh, and a browser.
People who have never tried a Chromebook like to say things like "they are for dummies who don't know anything about computers. A power user would never use one.". One guy I've spoken to, whom I consider to be a power user, had this to say about his new Chromebook:
"suspect I'll make this my primary laptop. I tend to like my laptops slightly smaller, but I think I can lug around this 1.5kg monster"
Maybe someone thinks that guy, Linus Torvalds, is a newbie, and doesn't understand the needs of power users like themselves. Okay, fine, lug around something that weighs three times as much and takes six times longer to boot if you want. Linus and I can look at kernel patches on our Chromebooks.
The Chromebook works far better for me if there is any appreciable amount of typing involved. Sure, you CAN put a tablet in a case with a little keyboard, but it's not made for that, and it shows. It doesn't sit comfortably in your lap as you type away like the laptop / Chromebook form factor does.
Chromebooks also tend to have much longer battery life.
I mostly use a large Android phone if I'm not working. I couldn't very well do much work on my phone. On a Chromebook I can (mostly I work in a terminal and a web browser). There is definitely a place for a Chromebook. Most of what I do, for work and play, I can do just fine on a Chromebook. The one thing that comes to mind it doesn't work well for is using Microsoft SQL Server Studio.
> The pen is mightier than the sword.
The penis, mightier than the sword
- Bill Clinton
I had a typo. Sales of PCs each year are 8% less than the previous year. That's really bad news for Microsoft in 2027.
> So they tried something, and it didn't work out for them.
They tried mobile and failed and tried again and failed again and tried again and failed again for 21 years before giving up.
Why have they kept trying to get into mobile? Because most computing devices sold today are mobile, the market for corded computers has been falling for several years, and is expected to continue to fall.
> The vast overwhelming majority of all PCs sold at retail come with Windows on them.
In 2011, 365 million PCs were sold. In 2015, 288 million. In 2016, 269 million. When your market is dropping 8% per year, that's not good. It's also not good for Microsoft that the percentage of PCs sold with Linux pre-installed increases every year. They are doing okay today - 269 million is a lot less than 365 million, but it's still a lot of computers. Have a look at what that curve looks like 10 years from now, though, as sales keep dropping 10% each year. There's a reason Microsoft is trying to sell Linux on the cloud - it's because they see the curve, they know they won't keep selling Windows on PCs.
Heck, they've stopped even TRYING to sell new versions of Windows, upgrades. In the 1990s people lined up around the block to pay $200 for the latest Windows upgrade. Now nobody buys a new Windows version, literally nobody at all.
> "Running Windows 7 disables or restricts these features:"
They don't know what all features in various updates may not work, and they don't want to figure that out for an officially obselete operating system. One thing that often may not work is booting. Installing from a OEM disk probably won't work because it won't have the drivers for a USB3 keyboard and mouse. Power management will often not work - once the machine goes to sleep, it may not wake up again.
APPLICATION code generally is tied to a specific instruction set and OS. Application code doesn't generally care about the hardware, because the operating system takes care of the hardware. On the other hand, the operating system DOES care about the hardware, and Skylake hardware is different. Skylake is NOT "Ivy Bridge, faster" - it's a different microarchitecture.
> USB3 worked before, it will work after (the USB2 specification has not changed, for example).
Windows 7 does not support USB3 out of the box. USB2 is not USB3. They have one thing in common - similar names. USB2 is a synchronous, half duplex protocol over
one pair of wires. USB3 is an asynchronous, full duplex protocol with three pairs.
> Microsoft tried, people preferred to choose between the OSes that are more popular. Mozilla tried Firefox OS, but that didn't work out either. BlackBerry's BBOS also couldn't find enough takers
> Do you think some company, or individual, should attempt to create their own mobile operating system?
Lots of people and companies DID try. Big companies and small.
> Ideally, the market is more consumer friendly when there are more than one or two dominant forces.
Apparently not in this instance, in which consumers are served by having a wide range of apps to choose from, on a wide range of hardware. Android offers hardware from $50 to $1,500, with millions of apps. Apparently that's what consumers want. They could have chosen Windows Mobile, or Firefox OS, or Blackberry, or several others. They prefer the well-known platforms with millions of apps and a wide choice of hardware.
There IS a third player - Samsung. Samsung's phones are "Android based" in the same way that Android is "Linux based".
> "Microsoft shares have doubled since he took the top job in early 2014"
> And so has almost every other share.
Not by a long shot.
The Dow was at about 17,000 in early 2014. It's now a bit below 23. Nasdaq went from 4,300 to 6,600. Microsoft went from $38 to $76.
So Microsoft has significantly outperformed other companies generally.
Compare Microsoft to the other leaders of the PC industry from 2014. The top three PC makers in 2014 were Lenovo, Dell, and HP. Lenovo has last half it's value. Dell went private to deal with "significant issues", and HP Inc dropped from $29 to $20.
>. But if Windows 7 is truly incompatible with Skylake CPUs, then doesn't that mean the Skylake CPU is not compatible with x64?
Applications written on / for Windows 7 should work on Skylake. The operating system needs to be concerned with more than just the instruction set. The OS has to support the busses in use (NVME and USB3), the power management scheme, the boot process (UEFI, not BIOS), hardware interrupts, etc. A few manufacturers have tested some of their Skylake models with Windows 7.
It goes both ways. A manufacturer isn't going to release a new high-power CPU that can't run any operating system. The CPU needs to "support" (be compatible with) some operating system, and the company making the CPU will likely need to be involved with the first OS port.
The case of AMD64, aka x64, is a good example. Before the CPU was actually produced, AMD made a emulator, then AMD and Suse ported Linux to the new instruction set. By actually running Linux on the new instruction set they could identify any problems with the CPU design design before making it in actual silicon.
Four years later, Microsoft released some x64 support in Windows. So you could say that first the hardware CPU was manufactured to support 64-bit Linux, which existed before the CPU was produced. Years later, Windows started supporting the CPU. Similarly, back in 1995, Linux added support for 64 Alpha processors, which existed before Linux supported them.
You are absolutely correct for SHA-1 hashes of random data, of significant length. Passwords, however, are neither random nor long. I'll describe the attack for you and you can try it out yourself. The fact that an ordinary consumer PC can compute SHA-1 password hashes at the rate 10 billion per second is why SHA-1 is no longer appropriate for passwords. Here's how the attack is done:
Download two large lists of passwords, any "combined list" from your favorite haxor site will do. It doesn't matter what sites the passwords are from. If you run a comparison, you'll find that given two lists of a million passwords, about half of the passwords will be on both lists - with different accounts. That is, there is about a 50/50 chance that your password is in the list because somebody else used the same password. You probably know it's not too hard to find lists totaling many millions of passwords (we don't need fresh ones). If we put together a list of 10 million passwords, most of the Disqus passwords will be on our list, because SOMEBODY used the same password (not necessarily the same person).
So we take the first, most common password on our list of previously seen passwords and try it against each of the 17 million hashes from Disqus. Because SHA-1 is so fast, our $100 GPU can check all 17 million hashes in one millisecond. In one second, we can try the top thousand most common passwords. In 24 hours, we can test out 10 MILLION passwords that somebody, somewhere, has used before, and thereby crack perhaps 8 million of the Disqus passwords - which gives us the email addresses to match those passwords.
For passwords, therefore, you need a hash that can't be easily computed at the rate of billions per second with commodity hardware. Bcrypt and scrypt are appropriate choices. To avoid certain problems with particularly long or particularly short passwords, you first take a SHA-2 hash of the password, then scrypt it.*
* In the general case of random data, hashing a hash doesn't add security. Passwords, however are not the general case.
> Also, I'm not sure about your reasoning on thrust being nearly proportional to blade length.
By Newton's third law, thrust is equal to the force applied to the air moved through the rotor disc. That's the area of the rotor disc times the average acceleration of the air (average velocity change). There are two terms there, disc area and AVERAGE Delta V of the air.
The disc area is proportional to the square of the rotor radius. On the other hand, the portion of the rotor near the hub has nearly zero linear velocity, and flows very little air. The majority of the thrust is generated nearer the rotor tips. The area of high thrust, say within 8 feet of the rotor tip, is essentially the circumference of the disc, and therefore linearly proportional to the rotor diameter.
So one term is linearly proportional to the rotor radius, one term to the square of the radius.
>. The big reason most helicopters have one rotor is simplicity in design, maintenance, and control.
A single 40 foot rotor has 4 times the disc area of two 20 foot rotors. Because thrust is the disc area multiplied by the average delta V, four times as much swept area makes a big difference in thrust. The one large rotor makes much more thrust than two rotors of half the diameter.
For fixed-wing craft (airplanes) blade tips CAN as you say, go supersonic, though that's quite rare because there is an enormous increase in drag at transonic speeds. Helicopters not only have the large increase in drag to worry about, but also in forward flight one wing is moving forward while the other wing in moving backward.
Consider the world's fastest military helicopter, the Chinook, flying forward at 315km/h. If the blade tip were moving at 1,000 km/h relative to the fuselage, the advancing blade would be moving through the air at 1,315, or Mach 1.1, while the retreating blade on the other side would have airspeed of 685 km/h. That would mean the advancing side of the rotor would be going twice as fast as the retreating side. You can imagine how it's pretty much impossible to design a rotor that can be moving at both supersonic speeds and very subsonic at the same time.
Additionally the blade tips at times enter the vortex of the other blade, which will cause local transonic flow, and disruption of the aerodynamics, if the "normal" velocity is even close to the speed of sound.
Practical designs for regular use are therefore limited to well under the speed of sound at the tips. This is no great loss because rotor drag is a function of the CUBE of the speed. While lift increases with the square of diameter, drag increases with the cube, so a large, slow rotor is better anyway.