Which is why Linus' policy is that, when the choice is between userland compatibility and better adherence to theoretical documentation of the kernel interface, tie goes to userland compatibility.
This is what major version increments are for, E.g. 2.4 as opposed to 2.2, or 2.6 as opposed to 2.4. API changes (even changes that are bugfixes, which break applications relying on bugs),
go in major version increments.
And application developers, then have sufficient warning, that there is a major version increment in the library or kernel, to indicate they need to perform compatibility testing with the new major release.
When the change is first introduced in unstable release 2.3, they test their application, and get it working with all the API changes before the start of the next stable line.
And the thing is, that happens. A lot. Even at microsoft. "That's the stupidest fucking thing I've ever heard!" - Bill Gates. And that was in Paul Allens book, and apparently an oft used phrase.
Why was no one around at Microsoft to say that when Windows 8 Start Menu removal, and Metro was being developed?
The developer wasn't being nasty, underhanded, manipulative, etc. It's possible to break user land by fixing broken behavior that userland depends on, and it's been an ongoing issue for all kernels. (Take a look at the history of the egcs variant compiler and Linux kernel compilation.)
Exactly.... Linus' suggested policy is totally b0rked.
Breakage of user programs that only worked by coincidence in the first place should not be concealed by keeping kernel bugs around.
They should test their code against the latest changes, and have a fix of their userland code out before the next stable kernel release.
No... i'm sure private enterprise will take it up. For the low low subscription fee of $60/month to American Weather; you'll get a rough idea of what tomorrow's forecast should be like; with a few simple clicks from your web browser.
Get the app for $50 + $100/month for the mobile phone version;
or "The Weather Channel (Premium Cable TV Channel)" for $90/month.
Preparation against catastrophic events?
So these satellites are able to turn back the storm, and prevent damage?
Preparation in this case means 'early warning'
The idea is that if people are notified of the risk of a storm striking earlier,
they will have more time to prepare, and therefore: their preparations will be
more effective, and thus damage will be reduced.
It won't be true in all cases -- sometimes the 'early warning' may be ignored,
because it hasn't shown to be reliable.
Also, the NOAA makes predictions, and predictions that far in advance
have some inherent uncertainty, due to technological limitations and limitations
of the science, modelling, and statistical techniques used in weather prediction.
Linus' developed Linux as a hobby; it's not his profession, so it follows he doesn't have to be professional.
He can be a total dick if he wants to be.
And in this case, he was. Not totally without merit, as the developer was kind of being a dick too, trying to blame a bug in the application (albeit, a bug, indeed, but exposed by a kernel bug).
Sure, it could be ported and rewritten, but why have a $100/hour finance professional spend time learning a new macro language and rewriting and validating his old functions/macros for a new spreadsheet platform?
That's why you hire on some bright kid off the street for $10/hour part time to port it to the new macro language.
In a few hours, you have your ported macros, and you only need the newer shinier spreadsheet program.
> If you believe the NSA is watching you, then try taking your meds and refer to the moderately paranoid measures.
The NSA watching and you hoping to evade is a no-win scenario. The NSA watches everyone's comms, possibly.
But if they have a reason to want to watch you specifically, as a government agency, their vast resources are sufficient that you are not going to hide.
I this day and age, they are likely able to deploy insect-sized drones to video your every move.
One or two commonl fly shaped things fly in, slip into your computer, attach to a few circuits,
or you suddenly one day get a "special" spam message, with a payload that your CPU responds to,
and loads custom firmware on the TPM chip, and suddenly your computer is a surveillance appliance,
recording and reporting everything to your NSA masters.
No, to be truly secure, you put it in a room with no windows, make sure the computer is unplugged
It's not truly secure though. You will never own a perfectly secure system.
A computer system is only secure if it provides sufficient assurance of required confidentiality, availability and integrity of the data;
if any of the 3 criteria are not able to be sufficiently assured, then the system is insecure.
Unplugging the computer, addresses the 1st standard criteria for assessing security: confidentiality cannot be easily breached remotely, because the machine has been turned off, and made unable to communicate.
However... unplugging has issues, regarding availability. Data that is not available to the required users is (by definition) not secure. And when the computer is unplugged, there is also no way of ensuring that the data does not become altered without permission
(eg, by subversion of the media, or by bit rot).
Ensuring data availability via Backups and disaster recovery also become problems. How do you ensure you have a backup of an unplugged computer behind a door whose lock you don't have a key to?
You break down the door... well, if you can break down the door, someone else can to.
Make sure the storage is not only sealed inside the computer but that its contents can be destroyed at the touch of a button AND that the contents self-destruct if the door to the room opens while the computer is powered on.
Sounds like a built-in security weakness.
You're forgetting, that security includes availability, not just confidentiality and integrity.
If the system causes your data to become permanently unreadable, then that event is a breach of security,
because availability of the data has been compromised.
IR#1 wasn't over until IR#2 was well under way; internal combustion engines took over benefits of railroads.
IR#2 wasn't over until IR#3 was well under way; computers, world wide web.
I would argue IR#4 exists.... mobile devices, social networking, genetically engineered products, is a completely separate IR.
And IR #5; intelligent computers, autonomous vehicles, robotic assistants, artificial lifeforms, nanotech,
digital experts (electronic delivery men, politicians, secretaries, police, workmen, ditch diggers, garbage collectors, firefighters, referees, judges, lawyers, doctors, engineers, programmers, artists,....) as good (or better) at the job than humans are yet to come.
No, his point was valid. You can always make a slow hash algorithm out of a fast one, for example by rehashing over and over again a 100K times.
Not true. The word always is very dangerous when you don't restrict it. You can always make a slow implementation of a hash algorithm by rehashing over and over again 100K times.
It may very well be that the result of performing all those 100K repetitions can be computed in a different way, that is barely any slower than 1 more repetition of the original hash, so your slow implementation that does 100K repetitions, is not the fastest way to accomplish them.
The star rating system is riddled with rubbish like "The book arrived on time and was in good condition. Would definitely recommend this seller. 10/10" and often worse "This book was late and the damaged. 0/10".
My recommendation would be to 'divide' the star rating into a Q and A; about 12 to 15 questions covering various generic things about the product.
One of the Q and As would ask if you authored a book in that area.
Instead of not getting to write a review -- the information should be disclosed.
Authors should be allowed to review books; the review system should just categorize them differently and prominently identify who wrote the review, and their 'history'.
Then, after the review is written and the questions are scored, the 'star' rating in various categories is a value calculated behind the scenes -- a value is computed to apply "weight" to each user's rating.
The number of reviews you wrote, would effect the weight of your review - if you just wrote a few reviews, or you have just joined, your reviews should have a lower weight than a more experienced reviewer.
If none of your reviews have been marked 'helpful' yet; your star rating should have little bearing on the overall star score of the item.
If all the reviews you wrote have high star scores; then your reviews should have little weight, unless your review is below what the star score would be otherwise.
If all the reviews you wrote have low star scores; then your reviews should have little weight, unless your review is above what the star score would be otherwise.
If you have a 'good mix' of the star scores you have reviewed items at -- then your review should bear greater weight,
as you are clearly expressing a dichotomy of opinion between good and bad - rather than reviewing only items
you had a prejudicing issue with, and marking them a score of 1, because of a bad experience with the seller,
OR reviewing everything you bought always at the maximum score, not bothering to make any distinction between
"very good" and "extremely superior" in characteristics buyers care about.
I'm considering using a blake2 64-bit authentication has in P2P messages. Any good reasons not to?
That may not be a very conservative choice from a security standpoint. The algorithm is new, and has less review/scrutiny and has stood less of a test of time than some other algorithms such as SHA1, RIPEMD-160, Tiger, VSH, Whirlpool. The protocol or its optimization may be broken in a subtle way that will be discovered within 2 to 6 years.
Even BLAKE the SHA-3 finalist may have stood less scrutiny so far.
Although; the finalist protocols for SHA3 will eventually be under a microscope, and a great deal of scrutiny from many crypto researchers. It remains to be seen of there will be an attack against new "optimized" version; frankly, I'm not sure how much scrutiny the optimized version will get if it's not also a finalist for SHA3, and it's not right now a widely used algorithm either.
I would suggest implementing the protocol in some manner with support for multiple choices of hashing algorithm, so you can upgrade later, or replace/transition away from the BLAKE-fast algorithm without breaking the network, if it turns out to have issues.
The only of these for which slower is better, is password storing. If you are using e.g. cryptographic hash functions with a 512-bit output, it is irrelevant for practical security that one hash function is a billion times faster than another.
No, it's not irrelevent. The 64-bit hash that cannot be sped up may be stronger than a 512-bit hash that can be computed quickly.
If the fast hash enables me to build an ASIC that can perform 10^150 hashing operations per second instead of 10^80,
then I will be able to find a collision on the weak hash within a few hours, whereas, the slower 64-bit hash might have been something that would take hundreds of years.
Either way, you will not find a collision in the lifetime of the universe without finding a weakness in the hash.
If the hash is as strong as it is intended to be.
If the hash has weaknesses (and most any hash certainly will have as of yet undiscovered weaknesses); the increased efficiency in computing the hash for the application, also results in increased efficiency of searching for a collision.
A collision search / attack against the security of the hash will require some very large number of hashing operations.
If the hash is more speed efficient, these attack operations will complete much more quickly.
and they will make money, because people are far more willing to pay a premium for a car to be fixed and there in the morning than spend taxi fares and such to drop a vehicle off in the day.
Why not just have a service where you lease the driverless car.
Whenever maintenance is required (including cleaning); your car may schedule a replacement vehicle to drive up to your doorstep.
Your effects will be automatically transferred to your new vehicle, by robotic assistants.
And you no longer need to worry about the old car, because it's a
VaaS (Vehicle As a Service) subscription that you have.
There's no longer a single car you own... you just have a monthly subscription fee, to have a ride of a certain make / model.
How would the car be able to detect that? But it could present quite a traffic hazard.
Not if all the cars are driverless cars, that reply on another input signaling method.
The cars could have front facing and rear-facing sensors, and a "self inspection" system that relies on other driverless cars on the road to facilitate the inspection.
The driverless car establishes a "data link" with an adjacent car behind it, and politely asks the car behind it, to help it self-inspect the integrity of its rear and the rear safety equipment.
A coded "PING" pulse is sent to the rear tail lights, by lighting the LED for a fraction of a millisecond, and encoding a very short message, and the car behind replies to the ping, by emitting a pulse through all its forward safety lights.
The car in front, then sends another pulse, to acknowledge receipt, so both cars know that their adjacent safety equipment is operational.
The encoded message contains a picture of the other car, which can be fed through a computer vision algorithm, to ensure the physical state matches expected.
to ticket a driverless car. The car, by design and foregoing any human intervention, will obey the law exactly as it is programmed to. It will not speed, it will not swerve,
It might have a window tinted too dark according to officer's opinion.
It might have a tail light out.
Its inspection sticker might be missing or not properly renewed.
It might have failed to obey a special road direction sign that the automated driver does not understand.
Such as a special speed minimum or maximum during only certain hours on Tuesdays.
Or a special direction on a certain road to "Keep left", or that only vehicles with a certain badge or of a certain type are allowed to use a certain lane.
The assumption that it follows the rules accurately requires standardization that might not always
exist in every jurisdiction.
This is already a career building success for me, and everyone acknowledges my technical capabilities. But the program manager is an MBA-type, and wants to bring in new multiple team leaders and consultants. This is not really a surprise, but I feel we are sliding towards a too-many-chiefs-too-few-indians scenario, especially at this early stage.
I get that you consider it your success, and you attribute success of the project so far to your technical abilities, and you see yourself as a chief.
But creating a personal success for you, or career-building for you, is likely not the priority for the organization.
The manager is obviously seeking to add leadership, to help ensure the project's success; and in particular,
that the project meets management business objectives.
If you see yourself as managing the project, and your boss both sees themselves as managing the project, sorry, but you lose.
Ultimately, it is up to the PM how to manage their project.
Meeting business objectives is more complicated than technical considerations; there are also concerns about things like
oh, cost.
So it may be sensible that additional leaders and consultants become involved, to help the business set the business objectives priorities,
expectations, and milestones the business will have for the project.
The technical abilities are one thing -- the choice of priorities, what things the technical resources are spent on, are
management decisions. Don't neglect your boss' management abilities in enabling the business to conduct the project
in the first place, staff it appropriately, and get the staff spending the man hours on the tasks that will help best meet the business
objectives as rapidly as possible.
Slashdot Mirror
Which is why Linus' policy is that, when the choice is between userland compatibility and better adherence to theoretical documentation of the kernel interface, tie goes to userland compatibility.
This is what major version increments are for, E.g. 2.4 as opposed to 2.2, or 2.6 as opposed to 2.4. API changes (even changes that are bugfixes, which break applications relying on bugs), go in major version increments.
And application developers, then have sufficient warning, that there is a major version increment in the library or kernel, to indicate they need to perform compatibility testing with the new major release. When the change is first introduced in unstable release 2.3, they test their application, and get it working with all the API changes before the start of the next stable line.
And the thing is, that happens. A lot. Even at microsoft. "That's the stupidest fucking thing I've ever heard!" - Bill Gates. And that was in Paul Allens book, and apparently an oft used phrase.
Why was no one around at Microsoft to say that when Windows 8 Start Menu removal, and Metro was being developed?
The developer wasn't being nasty, underhanded, manipulative, etc. It's possible to break user land by fixing broken behavior that userland depends on, and it's been an ongoing issue for all kernels. (Take a look at the history of the egcs variant compiler and Linux kernel compilation.)
Exactly.... Linus' suggested policy is totally b0rked.
Breakage of user programs that only worked by coincidence in the first place should not be concealed by keeping kernel bugs around.
They should test their code against the latest changes, and have a fix of their userland code out before the next stable kernel release.
No... i'm sure private enterprise will take it up. For the low low subscription fee of $60/month to American Weather; you'll get a rough idea of what tomorrow's forecast should be like; with a few simple clicks from your web browser.
Get the app for $50 + $100/month for the mobile phone version; or "The Weather Channel (Premium Cable TV Channel)" for $90/month.
Preparation against catastrophic events? So these satellites are able to turn back the storm, and prevent damage?
Preparation in this case means 'early warning'
The idea is that if people are notified of the risk of a storm striking earlier, they will have more time to prepare, and therefore: their preparations will be more effective, and thus damage will be reduced.
It won't be true in all cases -- sometimes the 'early warning' may be ignored, because it hasn't shown to be reliable. Also, the NOAA makes predictions, and predictions that far in advance have some inherent uncertainty, due to technological limitations and limitations of the science, modelling, and statistical techniques used in weather prediction.
Linus' developed Linux as a hobby; it's not his profession, so it follows he doesn't have to be professional. He can be a total dick if he wants to be.
And in this case, he was. Not totally without merit, as the developer was kind of being a dick too, trying to blame a bug in the application (albeit, a bug, indeed, but exposed by a kernel bug).
Sure, it could be ported and rewritten, but why have a $100/hour finance professional spend time learning a new macro language and rewriting and validating his old functions/macros for a new spreadsheet platform?
That's why you hire on some bright kid off the street for $10/hour part time to port it to the new macro language.
In a few hours, you have your ported macros, and you only need the newer shinier spreadsheet program.
It's (the end of) 2012, why the hell are people STILL putting their data stores in web-accessible directories below DocumentRoot?
For the same reason that people are still picking simple passwords. Because it's easy, and doing the right thing is less convenient.
> If you believe the NSA is watching you, then try taking your meds and refer to the moderately paranoid measures.
The NSA watching and you hoping to evade is a no-win scenario. The NSA watches everyone's comms, possibly. But if they have a reason to want to watch you specifically, as a government agency, their vast resources are sufficient that you are not going to hide.
I this day and age, they are likely able to deploy insect-sized drones to video your every move.
One or two commonl fly shaped things fly in, slip into your computer, attach to a few circuits, or you suddenly one day get a "special" spam message, with a payload that your CPU responds to, and loads custom firmware on the TPM chip, and suddenly your computer is a surveillance appliance, recording and reporting everything to your NSA masters.
No, to be truly secure, you put it in a room with no windows, make sure the computer is unplugged
It's not truly secure though. You will never own a perfectly secure system.
A computer system is only secure if it provides sufficient assurance of required confidentiality, availability and integrity of the data; if any of the 3 criteria are not able to be sufficiently assured, then the system is insecure.
Unplugging the computer, addresses the 1st standard criteria for assessing security: confidentiality cannot be easily breached remotely, because the machine has been turned off, and made unable to communicate.
However... unplugging has issues, regarding availability. Data that is not available to the required users is (by definition) not secure. And when the computer is unplugged, there is also no way of ensuring that the data does not become altered without permission (eg, by subversion of the media, or by bit rot).
Ensuring data availability via Backups and disaster recovery also become problems. How do you ensure you have a backup of an unplugged computer behind a door whose lock you don't have a key to? You break down the door... well, if you can break down the door, someone else can to.
Make sure the storage is not only sealed inside the computer but that its contents can be destroyed at the touch of a button AND that the contents self-destruct if the door to the room opens while the computer is powered on.
Sounds like a built-in security weakness. You're forgetting, that security includes availability, not just confidentiality and integrity. If the system causes your data to become permanently unreadable, then that event is a breach of security, because availability of the data has been compromised.
IR#1 wasn't over until IR#2 was well under way; internal combustion engines took over benefits of railroads.
IR#2 wasn't over until IR#3 was well under way; computers, world wide web.
I would argue IR#4 exists.... mobile devices, social networking, genetically engineered products, is a completely separate IR.
And IR #5; intelligent computers, autonomous vehicles, robotic assistants, artificial lifeforms, nanotech, digital experts (electronic delivery men, politicians, secretaries, police, workmen, ditch diggers, garbage collectors, firefighters, referees, judges, lawyers, doctors, engineers, programmers, artists, ....) as good (or better) at the job than humans are yet to come.
No, his point was valid. You can always make a slow hash algorithm out of a fast one, for example by rehashing over and over again a 100K times.
Not true. The word always is very dangerous when you don't restrict it. You can always make a slow implementation of a hash algorithm by rehashing over and over again 100K times.
It may very well be that the result of performing all those 100K repetitions can be computed in a different way, that is barely any slower than 1 more repetition of the original hash, so your slow implementation that does 100K repetitions, is not the fastest way to accomplish them.
Ergo, you don't have a slow hash at all.
The star rating system is riddled with rubbish like "The book arrived on time and was in good condition. Would definitely recommend this seller. 10/10" and often worse "This book was late and the damaged. 0/10".
My recommendation would be to 'divide' the star rating into a Q and A; about 12 to 15 questions covering various generic things about the product. One of the Q and As would ask if you authored a book in that area. Instead of not getting to write a review -- the information should be disclosed. Authors should be allowed to review books; the review system should just categorize them differently and prominently identify who wrote the review, and their 'history'.
Then, after the review is written and the questions are scored, the 'star' rating in various categories is a value calculated behind the scenes -- a value is computed to apply "weight" to each user's rating.
The number of reviews you wrote, would effect the weight of your review - if you just wrote a few reviews, or you have just joined, your reviews should have a lower weight than a more experienced reviewer.
If none of your reviews have been marked 'helpful' yet; your star rating should have little bearing on the overall star score of the item.
If all the reviews you wrote have high star scores; then your reviews should have little weight, unless your review is below what the star score would be otherwise.
If all the reviews you wrote have low star scores; then your reviews should have little weight, unless your review is above what the star score would be otherwise.
If you have a 'good mix' of the star scores you have reviewed items at -- then your review should bear greater weight, as you are clearly expressing a dichotomy of opinion between good and bad - rather than reviewing only items you had a prejudicing issue with, and marking them a score of 1, because of a bad experience with the seller, OR reviewing everything you bought always at the maximum score, not bothering to make any distinction between "very good" and "extremely superior" in characteristics buyers care about.
I'm considering using a blake2 64-bit authentication has in P2P messages. Any good reasons not to?
That may not be a very conservative choice from a security standpoint. The algorithm is new, and has less review/scrutiny and has stood less of a test of time than some other algorithms such as SHA1, RIPEMD-160, Tiger, VSH, Whirlpool. The protocol or its optimization may be broken in a subtle way that will be discovered within 2 to 6 years.
Even BLAKE the SHA-3 finalist may have stood less scrutiny so far. Although; the finalist protocols for SHA3 will eventually be under a microscope, and a great deal of scrutiny from many crypto researchers. It remains to be seen of there will be an attack against new "optimized" version; frankly, I'm not sure how much scrutiny the optimized version will get if it's not also a finalist for SHA3, and it's not right now a widely used algorithm either.
I would suggest implementing the protocol in some manner with support for multiple choices of hashing algorithm, so you can upgrade later, or replace/transition away from the BLAKE-fast algorithm without breaking the network, if it turns out to have issues.
There is a common method of doing this, by inserting a "HASH TYPE" header in front of a password. RFC2307
SHA256 CRYPT() with 10000 rounds - {SHA256-CRYPT}$5$rounds=100000$hK.9TGSGMfuVhMY1$ukBEvc3eTCJNgiK.BIsNIWmq9JU3D8tMapmqwJB6ip0
Cleartext password - {plain}password {clear}password
Traditional Unix crypt - {crypt}FHrLg6eHMx2nA
Unsalted MD5 - {md5}
Salted MD5 - {smd5}p47J0UeLzLY+/Lk7q0ohOnMJTGI=
Unix MD5 Crypt - {md5-crypt}$1$QgAqzRlm$Wo69omVJhJHZR2aOKJ4qs1
Unsalted SHA - {sha1}...
Unsalted SHA - {sha}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
Salted SHA1 - {ssha}Dh+8hirJLTZa79Pupbn4W5qbRMP9C7Bv
SHA256 - {sha256}
SHA512 - {sha512}
Salted SHA 256 - {ssha256}
Salted SHA 512 - {ssha512}
Windows NT Hash / MD5 - {nt}
NTLM - {ntlm}
Lanman - {lm}
{CRAM-MD5}
{plain-md4}(MD4 in hex)
{SKEY}....
The only of these for which slower is better, is password storing. If you are using e.g. cryptographic hash functions with a 512-bit output, it is irrelevant for practical security that one hash function is a billion times faster than another.
No, it's not irrelevent. The 64-bit hash that cannot be sped up may be stronger than a 512-bit hash that can be computed quickly.
If the fast hash enables me to build an ASIC that can perform 10^150 hashing operations per second instead of 10^80, then I will be able to find a collision on the weak hash within a few hours, whereas, the slower 64-bit hash might have been something that would take hundreds of years.
Either way, you will not find a collision in the lifetime of the universe without finding a weakness in the hash.
If the hash is as strong as it is intended to be.
If the hash has weaknesses (and most any hash certainly will have as of yet undiscovered weaknesses); the increased efficiency in computing the hash for the application, also results in increased efficiency of searching for a collision.
A collision search / attack against the security of the hash will require some very large number of hashing operations. If the hash is more speed efficient, these attack operations will complete much more quickly.
and they will make money, because people are far more willing to pay a premium for a car to be fixed and there in the morning than spend taxi fares and such to drop a vehicle off in the day.
Why not just have a service where you lease the driverless car. Whenever maintenance is required (including cleaning); your car may schedule a replacement vehicle to drive up to your doorstep.
Your effects will be automatically transferred to your new vehicle, by robotic assistants. And you no longer need to worry about the old car, because it's a VaaS (Vehicle As a Service) subscription that you have.
There's no longer a single car you own... you just have a monthly subscription fee, to have a ride of a certain make / model.
How would the car be able to detect that? But it could present quite a traffic hazard.
Not if all the cars are driverless cars, that reply on another input signaling method.
The cars could have front facing and rear-facing sensors, and a "self inspection" system that relies on other driverless cars on the road to facilitate the inspection.
The driverless car establishes a "data link" with an adjacent car behind it, and politely asks the car behind it, to help it self-inspect the integrity of its rear and the rear safety equipment.
A coded "PING" pulse is sent to the rear tail lights, by lighting the LED for a fraction of a millisecond, and encoding a very short message, and the car behind replies to the ping, by emitting a pulse through all its forward safety lights.
The car in front, then sends another pulse, to acknowledge receipt, so both cars know that their adjacent safety equipment is operational.
The encoded message contains a picture of the other car, which can be fed through a computer vision algorithm, to ensure the physical state matches expected.
to ticket a driverless car. The car, by design and foregoing any human intervention, will obey the law exactly as it is programmed to. It will not speed, it will not swerve,
It might have a window tinted too dark according to officer's opinion. It might have a tail light out. Its inspection sticker might be missing or not properly renewed.
It might have failed to obey a special road direction sign that the automated driver does not understand. Such as a special speed minimum or maximum during only certain hours on Tuesdays. Or a special direction on a certain road to "Keep left", or that only vehicles with a certain badge or of a certain type are allowed to use a certain lane.
The assumption that it follows the rules accurately requires standardization that might not always exist in every jurisdiction.
Lastly, I wonder if there are rules against the use of performance enhancing drugs for typing world records ;).
How about experience enhancing drugs, and predictive input?
You can't. But this will interfere with network Administrators implementing a technical policy of pre-deploying specified extensions for all users.
The only solution I can think of right now is to ban Chrome; and only allow IE or Firefox; which will allow admin-deployed extensions.
Perhaps due to limited / patent-restricted availability of the extraction method.
The price will likely decrease, when owners of large bee colonies start figuring out ways of capitalizing on this.
Or when biotech folks come up with a way of producing "synthetic" bee venom, grown by bacteria infused with genes extracted from the bees.
This is already a career building success for me, and everyone acknowledges my technical capabilities. But the program manager is an MBA-type, and wants to bring in new multiple team leaders and consultants. This is not really a surprise, but I feel we are sliding towards a too-many-chiefs-too-few-indians scenario, especially at this early stage.
I get that you consider it your success, and you attribute success of the project so far to your technical abilities, and you see yourself as a chief.
But creating a personal success for you, or career-building for you, is likely not the priority for the organization. The manager is obviously seeking to add leadership, to help ensure the project's success; and in particular, that the project meets management business objectives.
If you see yourself as managing the project, and your boss both sees themselves as managing the project, sorry, but you lose. Ultimately, it is up to the PM how to manage their project.
Meeting business objectives is more complicated than technical considerations; there are also concerns about things like oh, cost.
So it may be sensible that additional leaders and consultants become involved, to help the business set the business objectives priorities, expectations, and milestones the business will have for the project.
The technical abilities are one thing -- the choice of priorities, what things the technical resources are spent on, are management decisions. Don't neglect your boss' management abilities in enabling the business to conduct the project in the first place, staff it appropriately, and get the staff spending the man hours on the tasks that will help best meet the business objectives as rapidly as possible.