It seems to me that since high-quality free kernels are available, it would be stupid to NOT spend a few minutes considering the option. They must have thought about it *a little bit*. How seriously they considered / consider it is the question.
I think there are two possible explanations for this.
Most likely: The boss figured out there is no reason for Microsoft to keep developing their own kernel when they can just slap their UI on top of Linux. The boss said "port the system internals to Linux". A programmer got confused and ported SysInternals", the toolkit for seeing the system internals.
Also likely:
The eventual goal is to switch the system internals to Linux. In Agile fashion, Microsoft figured they'd start with a bite-sizdd chunk work that feels like it might be kinda going in that direction. It won't actually be used in the end, because it wasn't planned out, it was Scrumed.
Of Chinese spies are even halfway doing their job, they'll be taking advantage of the fact that so many countries use so much gear made in China. They should be fired and may be executed if they aren't doing this.
Maybe an example would make it more clear. The Emrax 268 is a 20kw motor. It weighs 44 pounds. To provide the 20kw needed to power that 44 pound motor, you'd need a 4,400 pound fuel cell. Plus the hydrogen.
That Emrax 268 is appropriate for a 3,000 plane. To power a motor capable of lifting 3,000 pounds of plane, you need 4,400 pounds of fuel cell.
Ergo a hydrogen fuel-cell plane can't get off the ground - it's too heavy, it doesn't provide enough power to lift itself.
> Specific power is related to fuel and its weight.
That's called specific energy. Power is how much can be done right now. Energy is how much can be done for how long.
Horsepower is power. Watts are power. You measure the power of a motor. Watt-hours measures energy. You measure the energy of a battery or an amount of fuel.
Hydrogen gas decent specific energy (you can go far without carrying much hydrogen), but only if you ignore the weight of the tank, which can weigh a lot.more than the hydrogen.
Hydrogen fuel cells have horrible specific power - it makes a weak motor, because they can't provide a lot of power at any given time. You need a huge fuel cell to power a tiny motor.
It wasn't civil engineering projects that she did.
A couple of her projects included:
Building Dell's innovative customer order to inventory to manufacturing system. With this system, when a customer orders a custom-confugured computer via Dell.com, it immediately checks the inventory of parts and orders new parts from the suppliers as needed. Based on parts availability and all of the computers scheduled to be built, it then schedules that particular computer to be built on the assembly line. The assembly line scheduling optimizes for several factors to make it more efficient - orders using similar parts are batched together. Shipping is scheduled similarly. Within a few seconds after the customer places the order, the system knows when it will be assembled and placed into the box, within a margin of a few minutes.
Designing an integrated information system for Martin Marietta, an enterprise consisting of many companies in different fields, including mining and aerospace.
Her method for determining requirements was NOT asking the users' boss what they think they need.
Her methods also did NOT involve throwing shit and the wall and see what sticks (Agile, as often practiced).
The entire system was designed, in detail, based on *actual* requirements, not what some manager thought of when asked "what do you want?"
Three major parts of determining requirements included: 1. *Watching* the assembly line workers build the computers and taking detailed notes of what users *do*. (Not asking their boss's manager what they do, actually watching).
2. Documenting business inputs and outputs. Inputs include customer orders and vendor shipments. The key output is computers shipped to customers. (Note there are no integers or floats af the top level - these are business inputs, not data formats).
3. Analyzing the legacy systems, computer based and paper based, that did the same operations less well. Especially the databases were analyzed. If you understand the databases that run an enterprise, you will understand the operations of the enterprise better than any C suite executive does.
> half-finished software done is the only way to get the customer to actually start trying to say what they wanted instead of just waving the question away.
If that's the only way you've been taught, that's the only way you know. It's not the only way!
Largely that misconception comes from starting with the idea that you can only determine requirements based on "rhe customer saying what they wanted", or more commonly, the customers' boss's boss saying what they think.
You CAN document, in detail, the exact requirements for a complex $15 million project, without building anything first. Proof is most every civil engineering project ever. My mentor routinely did that with software projects. But you can't do it if you haven't been taught how.
You claimed I was incorrect about the power to weight ratio, also known as specific power. Specific power is, by definition, the power (watts) divided by the weight in kilograms. Weight is very much relevant to calculating power divided by weight.
The summary has it wrong. According to Scrum.org, Agile is *not* supposed to improve quality, that's not one of its goals, and indeed it deliberately chooses to sacrifice quality in order to achieve it's goals.
Agile has two main goals it can achieve: 1. Working around the fact that most programmer were never taught how to properly determine requirements.
2. Getting partial implementations out the door faster, so the organization can get part of the benefit before the system is finished.
By giving up on teaching how to determine and document requirements, quality is reduced.
By purposely pushing out code before it's done, as soon as it might be somewhat useful, quality is reduced.
That's not to say Agile is bad. Getting half-finished software TODAY instead of completely finished software three months from now may be very valuable in many cases. It just doesn't improve quality.
I agree there is a reason it's called calendar time. Because it's what people use for calendars. That's its appropriate use. If we set an appointment for 9:00 AM November 1, 2023, we mean when the clock reads those values - whatever time that happens to be. We don't yet know what time that will actually be (how many seconds away it is) because we don't know whether DST will be in effect.
You're slightly mistaken about epoch time and leap seconds. Epoch time is how long it has been since the epoch. Epoch time doesn't CARE if calendar time had a leap second or not. Epoch time can't get leap seconds or DST or leap years wrong because there is no school thing in epoch time. What you may havr seen is that someone trying to convert calendar time to epoch time got it wrong. People normally get it wrong in several different ways.
> In Germany there is a market for high power fuel cells in the range of up to10kW - 20kW
And those weigh thousands of kilograms, therefore their social power is a few watts. As originally noted within parentheses, specific power means power-to-weight ratio, how many watts per kilogram.
It's a lot like specific energy, where hydrogen again sucks because it requires a pressure vessel that weighs more than the fuel does.
UTC is certainly the right time zone to use where you, for some reason, need to store a human-readable string that represents a time. Most of the time relared problems and bugs aren't solved by storing times as UTC, though.
The thing is, you can't get your time calculations right when using year-month-day hour-minute-second format. Almost every professional implementation has had bad bugs. Even if you DID get it bug free, we'd break it after you ship it because we change the rules from time to time.
How many seconds are in a minute? It's not always sixty seconds.
What time comes after 23:59 59, in UTC. If you said midnight, as a programmer, you're wrong (sometimes it's 23:59:60 UTC, such as on December 31, 2016).
The way to store times as as an integer since the epoch. Unix, Linux etc set the epoch at January 1, 1970. The current Unix epoch time is therefore 1541311061. (That's how many seconds have elapsed since the epoch). Any recent choice of epoch is fine, unless your concerned about times centuries ago.
When you try to store an manipulate times as strings, you end up with crap like time going backwards, which breaks all kinds of things.
The only sort-of exception is I wouldn't yell at you for using the temporal types in a well-established relational database like MySQL and MS SQL. They do have bugs, and storing it as a number is more accurate, but the Mysql date handling isn't atrocious.
The basic idea of a fuel cell seems so cool. The actual physics suck. The practical considerations of trying to use them utterly suck. They aren't close to being practical for other than some niche uses.
Here's some more info from people who have built fuel cell vehicles, including a couple of good links in the article: https://energypost.eu/hydrogen...
As for aircraft, in aircraft design it's all about weight. Decrease the weight and you increase the efficiency, speed, and performance. Unfortunately fuel cells weigh 30 times as much as turbine engines - and still need to be attached to a motor. Turbine engine specific power (power-to-weight ratio) is measured in kilowatts, fuel cell specific power in watts.
Indeed airplane design is largely about keeping weight as low as possible. The lighter the plane is, the farther, faster, and better it will fly per [any useful measurement]. Pretty much anything you try to improve on a plane can be improved by reducing the weight and then re-optimizing* the other parameters, especially fuel efficiency.
Tomorrow I'll finish building yet another electric-powered model I'm building. It flies for a long time for a battery-powered model, 20 minutes of more. To achieve that, I ended up with a max speed of only about 22 MPH. To make the batteries last twice as long, I'd need about four times as much battery, because roughly half the battery power is used to lift the batteries.
* Someone who knows gliders may be thinking about the fact that a glider will go faster if you add weight. That's true it'll glide for a shorter time, faster - if nothing else changes. If you don't optimize for the lighter weight, it'll go down faster and go forward faster. If you DO design for the lighter weight, the lighter glider will plain fly better all around.
This could be slightly more significant than one might think. While these small planes aren't the main type most people think of when they think of "airplanes", they happen to be roughly the least efficient transportation available. Less efficient per passenger than large airliners.
To give one well-known example, when Al Gore and his wife go to dinner, his G-11 B burns 578 gallons per hour. ( 0.8 mpg).
Replacing transportation that gets 0.8 MPG with potentially renewable energy is an easy win.
In engineering, if it's wrong, it's probably better not to build it. Building something wrong, so it doesn't work and is perhaps dangerous, is not a success.
A cool thing about documenting standards is you can then translate that English-language documentation into a Git hook and it'll be checked *automatically* as soon as it's committed. The developer will be notified of the problem even before any other person sees it.
When people point out he's lying, Trump says it's fake news, and the journalists are terrible people. He sure is good at drumming up publicity though, getting people talking. One way Trump does that is saying it's going to be huge. The biggest ever.
When the major papers (and regulators) point out Musk was lying, he says it's fake news and the journalists are "terrible people, just terrible". Musk sure is good at drumming up publicity though, getting people talking. One way Musk does that is saying whatever he's doing is going to be huge, the biggest ever. With 0.01% of the auto market, he's convinced a *lot* of people that his tiny little boutique car maker will be the largest auto manufacturer in the world any day now.
Musk *is* Trump. If you look on the bottom of their foot, you'll see they are both the same model number, cast from the same mold.
They already have maintenance fees. Those fees make it harder for patent trolls.
Regarding bankruptcy:
Suppose I invented a new tool to fix car engines without taking everything apart, so it makes repairs much quicker and cheaper. It's a great invention. You loan me $20,000 to try to build a business around making and selling thr invention. I'm not the best business person in the world, I can't figure out how to best market the invention. I fail. My new tool company is bankrupt.
Snap-On offers $100,000 for the invention. You're excited - you can finally get back the $20,000 that you loaned me. Then you realize you're never getting your money back because *you* decided that if the original inventor doesn't also happen to be a great business person and fails, the patent is invalidated. An inventor can't sell the patent to someone who can actually manufacture and market it if they fail to build a business around it.
Ps, while Gilsap previously had 39% of HVP filings, Judge Robert William Schroeder III, had 24%. That's 63% for just those two judges.
After TC Heartland, only 3% of filings go to Schroeder.
Some people think that to fix this we have to completely throw out the patent system. These two judges, two people, were 63% of the problem. Handle those two guys and you're most of the way there.
Slashdot Mirror
It seems to me that since high-quality free kernels are available, it would be stupid to NOT spend a few minutes considering the option. They must have thought about it *a little bit*. How seriously they considered / consider it is the question.
I think there are two possible explanations for this.
Most likely:
The boss figured out there is no reason for Microsoft to keep developing their own kernel when they can just slap their UI on top of Linux. The boss said "port the system internals to Linux". A programmer got confused and ported SysInternals", the toolkit for seeing the system internals.
Also likely:
The eventual goal is to switch the system internals to Linux.
In Agile fashion, Microsoft figured they'd start with a bite-sizdd chunk work that feels like it might be kinda going in that direction. It won't actually be used in the end, because it wasn't planned out, it was Scrumed.
Of Chinese spies are even halfway doing their job, they'll be taking advantage of the fact that so many countries use so much gear made in China. They should be fired and may be executed if they aren't doing this.
Maybe an example would make it more clear. The Emrax 268 is a 20kw motor. It weighs 44 pounds. To provide the 20kw needed to power that 44 pound motor, you'd need a 4,400 pound fuel cell. Plus the hydrogen.
That Emrax 268 is appropriate for a 3,000 plane. To power a motor capable of lifting 3,000 pounds of plane, you need 4,400 pounds of fuel cell.
Ergo a hydrogen fuel-cell plane can't get off the ground - it's too heavy, it doesn't provide enough power to lift itself.
> Specific power is related to fuel and its weight.
That's called specific energy. Power is how much can be done right now. Energy is how much can be done for how long.
Horsepower is power. Watts are power. You measure the power of a motor.
Watt-hours measures energy. You measure the energy of a battery or an amount of fuel.
Hydrogen gas decent specific energy (you can go far without carrying much hydrogen), but only if you ignore the weight of the tank, which can weigh a lot.more than the hydrogen.
Hydrogen fuel cells have horrible specific power - it makes a weak motor, because they can't provide a lot of power at any given time. You need a huge fuel cell to power a tiny motor.
It wasn't civil engineering projects that she did.
A couple of her projects included:
Building Dell's innovative customer order to inventory to manufacturing system. With this system, when a customer orders a custom-confugured computer via Dell.com, it immediately checks the inventory of parts and orders new parts from the suppliers as needed. Based on parts availability and all of the computers scheduled to be built, it then schedules that particular computer to be built on the assembly line. The assembly line scheduling optimizes for several factors to make it more efficient - orders using similar parts are batched together. Shipping is scheduled similarly. Within a few seconds after the customer places the order, the system knows when it will be assembled and placed into the box, within a margin of a few minutes.
Designing an integrated information system for Martin Marietta, an enterprise consisting of many companies in different fields, including mining and aerospace.
Her method for determining requirements was NOT asking the users' boss what they think they need.
Her methods also did NOT involve throwing shit and the wall and see what sticks (Agile, as often practiced).
The entire system was designed, in detail, based on *actual* requirements, not what some manager thought of when asked "what do you want?"
Three major parts of determining requirements included:
1. *Watching* the assembly line workers build the computers and taking detailed notes of what users *do*. (Not asking their boss's manager what they do, actually watching).
2. Documenting business inputs and outputs. Inputs include customer orders and vendor shipments. The key output is computers shipped to customers. (Note there are no integers or floats af the top level - these are business inputs, not data formats).
3. Analyzing the legacy systems, computer based and paper based, that did the same operations less well. Especially the databases were analyzed. If you understand the databases that run an enterprise, you will understand the operations of the enterprise better than any C suite executive does.
> half-finished software done is the only way to get the customer to actually start trying to say what they wanted instead of just waving the question away.
If that's the only way you've been taught, that's the only way you know. It's not the only way!
Largely that misconception comes from starting with the idea that you can only determine requirements based on "rhe customer saying what they wanted", or more commonly, the customers' boss's boss saying what they think.
You CAN document, in detail, the exact requirements for a complex $15 million project, without building anything first. Proof is most every civil engineering project ever. My mentor routinely did that with software projects. But you can't do it if you haven't been taught how.
> The weight is completely irrelevant.
You claimed I was incorrect about the power to weight ratio, also known as specific power. Specific power is, by definition, the power (watts) divided by the weight in kilograms. Weight is very much relevant to calculating power divided by weight.
The summary has it wrong.
According to Scrum.org, Agile is *not* supposed to improve quality, that's not one of its goals, and indeed it deliberately chooses to sacrifice quality in order to achieve it's goals.
Agile has two main goals it can achieve:
1. Working around the fact that most programmer were never taught how to properly determine requirements.
2. Getting partial implementations out the door faster, so the organization can get part of the benefit before the system is finished.
By giving up on teaching how to determine and document requirements, quality is reduced.
By purposely pushing out code before it's done, as soon as it might be somewhat useful, quality is reduced.
That's not to say Agile is bad. Getting half-finished software TODAY instead of completely finished software three months from now may be very valuable in many cases. It just doesn't improve quality.
I agree there is a reason it's called calendar time.
Because it's what people use for calendars.
That's its appropriate use. If we set an appointment for 9:00 AM November 1, 2023, we mean when the clock reads those values - whatever time that happens to be. We don't yet know what time that will actually be (how many seconds away it is) because we don't know whether DST will be in effect.
You're slightly mistaken about epoch time and leap seconds.
Epoch time is how long it has been since the epoch. Epoch time doesn't CARE if calendar time had a leap second or not. Epoch time can't get leap seconds or DST or leap years wrong because there is no school thing in epoch time. What you may havr seen is that someone trying to convert calendar time to epoch time got it wrong. People normally get it wrong in several different ways.
> In Germany there is a market for high power fuel cells in the range of up to10kW - 20kW
And those weigh thousands of kilograms, therefore their social power is a few watts. As originally noted within parentheses, specific power means power-to-weight ratio, how many watts per kilogram.
It's a lot like specific energy, where hydrogen again sucks because it requires a pressure vessel that weighs more than the fuel does.
UTC is certainly the right time zone to use where you, for some reason, need to store a human-readable string that represents a time. Most of the time relared problems and bugs aren't solved by storing times as UTC, though.
The thing is, you can't get your time calculations right when using year-month-day hour-minute-second format. Almost every professional implementation has had bad bugs. Even if you DID get it bug free, we'd break it after you ship it because we change the rules from time to time.
How many seconds are in a minute?
It's not always sixty seconds.
What time comes after 23:59 59, in UTC.
If you said midnight, as a programmer, you're wrong (sometimes it's 23:59:60 UTC, such as on December 31, 2016).
The way to store times as as an integer since the epoch. Unix, Linux etc set the epoch at January 1, 1970. The current Unix epoch time is therefore 1541311061. (That's how many seconds have elapsed since the epoch). Any recent choice of epoch is fine, unless your concerned about times centuries ago.
When you try to store an manipulate times as strings, you end up with crap like time going backwards, which breaks all kinds of things.
The only sort-of exception is I wouldn't yell at you for using the temporal types in a well-established relational database like MySQL and MS SQL. They do have bugs, and storing it as a number is more accurate, but the Mysql date handling isn't atrocious.
The basic idea of a fuel cell seems so cool.
The actual physics suck. The practical considerations of trying to use them utterly suck. They aren't close to being practical for other than some niche uses.
Here's some more info from people who have built fuel cell vehicles, including a couple of good links in the article:
https://energypost.eu/hydrogen...
As for aircraft, in aircraft design it's all about weight.
Decrease the weight and you increase the efficiency, speed, and performance. Unfortunately fuel cells weigh 30 times as much as turbine engines - and still need to be attached to a motor. Turbine engine specific power (power-to-weight ratio) is measured in kilowatts, fuel cell specific power in watts.
Indeed airplane design is largely about keeping weight as low as possible. The lighter the plane is, the farther, faster, and better it will fly per [any useful measurement]. Pretty much anything you try to improve on a plane can be improved by reducing the weight and then re-optimizing* the other parameters, especially fuel efficiency.
Tomorrow I'll finish building yet another electric-powered model I'm building. It flies for a long time for a battery-powered model, 20 minutes of more. To achieve that, I ended up with a max speed of only about 22 MPH. To make the batteries last twice as long, I'd need about four times as much battery, because roughly half the battery power is used to lift the batteries.
* Someone who knows gliders may be thinking about the fact that a glider will go faster if you add weight. That's true it'll glide for a shorter time, faster - if nothing else changes. If you don't optimize for the lighter weight, it'll go down faster and go forward faster. If you DO design for the lighter weight, the lighter glider will plain fly better all around.
You're telling me stoned people did something stupid? Now way!
(Former stoner here. My income has increased 500% since I stopped getting stoned.)
Mpg = mph / gph
This could be slightly more significant than one might think. While these small planes aren't the main type most people think of when they think of "airplanes", they happen to be roughly the least efficient transportation available. Less efficient per passenger than large airliners.
To give one well-known example, when Al Gore and his wife go to dinner, his G-11 B burns 578 gallons per hour. ( 0.8 mpg).
Replacing transportation that gets 0.8 MPG with potentially renewable energy is an easy win.
In engineering, if it's wrong, it's probably better not to build it.
Building something wrong, so it doesn't work and is perhaps dangerous, is not a success.
A cool thing about documenting standards is you can then translate that English-language documentation into a Git hook and it'll be checked *automatically* as soon as it's committed. The developer will be notified of the problem even before any other person sees it.
When people point out he's lying, Trump says it's fake news, and the journalists are terrible people. He sure is good at drumming up publicity though, getting people talking. One way Trump does that is saying it's going to be huge. The biggest ever.
When the major papers (and regulators) point out Musk was lying, he says it's fake news and the journalists are "terrible people, just terrible". Musk sure is good at drumming up publicity though, getting people talking. One way Musk does that is saying whatever he's doing is going to be huge, the biggest ever. With 0.01% of the auto market, he's convinced a *lot* of people that his tiny little boutique car maker will be the largest auto manufacturer in the world any day now.
Musk *is* Trump. If you look on the bottom of their foot, you'll see they are both the same model number, cast from the same mold.
Your first sentence was:
--
I think any patents held by a company in bankruptcy should be thrown into the public domain.
--
Did you forget what you said?
Okay now THAT is scary
They already have maintenance fees. Those fees make it harder for patent trolls.
Regarding bankruptcy:
Suppose I invented a new tool to fix car engines without taking everything apart, so it makes repairs much quicker and cheaper. It's a great invention. You loan me $20,000 to try to build a business around making and selling thr invention.
I'm not the best business person in the world, I can't figure out how to best market the invention. I fail. My new tool company is bankrupt.
Snap-On offers $100,000 for the invention. You're excited - you can finally get back the $20,000 that you loaned me.
Then you realize you're never getting your money back because *you* decided that if the original inventor doesn't also happen to be a great business person and fails, the patent is invalidated. An inventor can't sell the patent to someone who can actually manufacture and market it if they fail to build a business around it.
Still seem like a great idea?
When plaintiffs could choose the judge, the picked Gilsap. Especially high volume plaintiffs (mostly trolls) picked Gilsap and Schroeder.
Why do *you* think trolls *chose* to file in Gilsap's court?
Ps, while Gilsap previously had 39% of HVP filings, Judge Robert William Schroeder III, had 24%. That's 63% for just those two judges.
After TC Heartland, only 3% of filings go to Schroeder.
Some people think that to fix this we have to completely throw out the patent system. These two judges, two people, were 63% of the problem. Handle those two guys and you're most of the way there.