> With email there's a trail, it can trivially be secured with GPG
And with DKIM signatures (needed to send email to Yahoo users) you can even prove that the message in evidence is actually what they sent - it hasn't been modified. Podesta, Donna Brazile, and Time Kaine found that out the hard way.
The framework isn't *just* a Perl, it was written for Linux. It checks/proc/cpuinfo, for example. Actually in some cases it uses *nix stuff where it should be using Perl. The other day I fixed this bit of "Perl":
The scenario you describe is something I fear, so just last night I worked to avoid it. Management is very concerned about some problems we had and they want to know what went wrong. Without going into detail, we had some bad code which caused a problem they noticed, problems that could affect revenue. I told them I would find the problem and report on how we can prevent a recurrence.
So this weekend I identified the problems in the code. I didn't start by telling top management the details of the bug; I my message to management starts with "last week, we paid some interest on our technical debt, previously known quality issues caused the situation. Recurrence of similar problems can be avoided by investing in correcting known issues in the code, rather than deferring this work as 'not high priority'. Specifically, the following known issues were involved in causing the problem, other issues may have also played a part...."
Management from the president down really want to make sure that problems like we had last week don't happen again. After hearing that the cause is various forms of technical debt, I expect management will decide we need to get rid of this nasty technical debt, to the extent that we can.
You insightfully identified the issue as "there is no one holding you accountable for paying back the former", part of my job, therefore, is to honestly inform them about the costs, so that the president of company holds middle managers responsible for addressing the issue. Another, similar, issue with tech debt is that it's normally not measured and doesn't appear on reports. Wise management, when they decide to incur tech debt (rush systems development) could write down a number for how much engineers estimate it will cost to a) maintain the less-robust system and b) eventually clean it up, making it more robust.
Has anyone used the new REST API they are replacing bulletins with? I've had trouble finding information about it, other than being told it's in no way RESTful.
> I think I'm gonna increase my MSFT position just in case.
Best of luck with that. I've always done mutual funds instead of trying to pick. I often discussed this with my best friend, who would always pick stocks. One day, in early 2008, he told me that rather than picking one company he had made a can't-lose buy: both Intel and AMD. Being the only two processor manufacturers with any significant market share, one of them would have to do well! Of course that was just about the time Android was released and most processor sales started to be ARM devices, neither Intel nor AMD.
Had I been more clever, I would have worked in a Netcraft joke and made it funny. Instead, I just accidentally typed Netcraft when I meant to type Statcounter.
I'm sure others have come up with slightly different numbers, but the point stands regardless. MS has gone from complete monopoly, what everyone used, to a minority - their market share of current *sales* is even less than the 38% statcounter shows. Yet they've managed to maintain and even grow revenue. Of course some of that is the fact that they actually make money on every Android device sold.:)
Which is amazing considering that a few years ago, 98% of people used their flagship product, Windows, while now only 38% of people do (Netcraft, 2016). They've done a really good job pivoting to maintain revenue while customers have dumped their traditional products en masse.
In 20 years, I've had exactly one occasion to run Linux stuff on Windows. I've had one other program I ran on Windows, that I can recall.
We have a framework on Linux, written mostly in Perl, which runs hundreds of small tools. We wanted to add a specific Windows-only tool to our system. So the g framework is installed under Cygwin on a few machines to run that one Windows tool.
No interpretation required. The FBI announced that she was without a doubt "very careless with classified information." That's a fact. The relevant crime is being "negligent" with classified information. That's a fact, no interpretation.
It's also a fact that in the same announcement, FBI director Comey, appointed by Obama, stated that other people would be prosecuted if they were similarly negligent. I'm not interpreting anything, that's what the FBI announced.
Did you play baccarat in Europe. There are three major varieties of baccarat. In North American casinos, Punto Banco is common. I understand in Punto Banco all players are playing against the house, similar to blackjack.
> having the average computer user familiar with using the command line
Perhaps. Having the average computer user exposing their scripts to internet is very dangerous. Which made it much easier when I learned, before the www was a thing.
> A huge number of professions would benefit from people being able to script up something to reduce their work load. > There are companies still doing books in Excel by hand (not relying on any of Excel's built in functions).
That is a great example. In 1990-2000, VBA scripting was something that could be very useful to a lot of people. These days, the spreadsheet is probably in the cloud (on the internet), pulling data from some source on the internet. Having people who can almost barely code creating code for your business, including those web-enabled spreadsheets, will very likely end up with one of them making all your data from your spreadsheets available online.
As someone who learned to code in the 1980s, writing various types of macros and shell scripts that I ran on my computer, I feel for anyone starting to learn now. These days, most code is exposed to the web in some way, so it's attacked a hundred times per day. It's awfully hard to learn b safely in a business environment, when the smallest mistake will be exploited by hackers.
Huh?!?!? Are you saying the stuff she lied about was immaterial to the investigation? She was being being investigated for sending classified information via a non-secure email system. She said "I did not send material marked classified over non-secure email". How the hell is that immaterial to the subject of the investigation?
PS, as is often the case with the Clintons, her words were *very* carefully chosen to say one thing to anyone listening, while technically saying something completely different, in her mind. She said "I never sent material *marked* classified. She [unlawfully] removed the markings, in most cases (but not always, so it was a lie both ways).
> no problem at all with safe recreational use but calling it "medical marijuana" is just an insult to the intelligence of anyone with a functioning brain.
No problem, then. The term is used by and for potheads, not for people with a functioning brain.
Many years ago, I was into NORML and the marijuana legalization movement. (We called it "decriminalization".) I wrote some articles that were well received by my NORML peers. Looking back on what I wrote now, I think "what the hell? Wtf was I smoking when I wrote THIS? You'd have to be stoned out of your mind to believe any of this crap." Then I remember wtf I was smoking, and that my readers were indeed stoned out of their mind.
The federal perjury statute says a person is guilty of perjury if they lie in either of these two types of instances" A) They've taken an oath in front of *any* court or competent *person* in any circumstance in which federal law allows an oath. Or B) Any written statement declaring "under penalty bof perjury", including a DMCA notice and certain customs forms.
Here's the actual text of the statute:
Whoeverâ" (1) having taken an oath before a competent tribunal, officer, or person, in any case in which a law of the United States authorizes an oath to be administered, that he will testify, declare, depose, or certify truly, or that any written testimony, declaration, deposition, or certificate by him subscribed, is true, willfully and contrary to such oath states or subscribes any material matter which he does not believe to be true; or (2) in any declaration, certificate, verification, or statement under penalty of perjury...
* In a DMCA notice, the complainant swears under penalty lf perjury that they are the copyright holder or the copyright holder's representative. They do NOT swear under penalty of perjury that a jury won't later determine that it's fair use or any other issue of law.
I've been working in open source for 20 years, so I'll share my thoughts. I don't have statistics, and it would be hard to define statistics that aren't misleading. For example, counting the number of projects would count a script I wrote in two hours equally with the Linux kernel, or the Apache web server. So counting the number of projects doesn't make much sense.
A very common scenario is work done by a companies that use the software, but don't run the project. At my last job, I spent a lot of time developing Moodle, an open source ecampus software. The university I worked for was one of hundreds of schools and companies that use Moodle. I worked on features in Moodle that would be of use to the college I worked for. I suspect this model accounts for most of the hours spent working on open source, though possibly not most of the people or projects. Moodle was started as a master's thesis (or maybe phd).
I expect that the largest number of *projects* may be hobbyists and school-related (including masters and phd projects). Many, many people have released many, many small projects. Often, these are just enough to do the job, not as highly polished as something that has a marketing team trying to sell it. Sometimes they are well polished, but often not - if it works, that's often enough. These also tend to be projects that hobbyists *use*. Companies tend to sponsor projects used by companies, hobbysts tend to work on projects they use for their hobbies.
I would say that a minority of projects, but often big, important projects, are have a lot of development from a company selling a version of the software or support and related materials. Mysql and RedHat are good examples. These tend to include software used by companies. If thousands of companies are using some software, there is probably an opportunity to create a company providing support to them. Often, these projects started as hobbyist / school projects, and the company was founded after the software was successful.
Another set is formerly proprietary software that has been open sourced and is supported by the company. That would include Netscape/Firefox.
So I'd say the statistics depend on which statistics you look at. Most projects? Hobbyist. Most hours invested? Businesses that use the software. Most important? Often both developed by businesses that use it and a company that coordinates the project.
* After Moodle started being used by different schools, each contributing code, a company was set up to coordinate development, with a QA department, etc. The schools and companies who use Moodle develop features, the Moodle company makes sure that doesn't turn into chaos.
Based on other comments, it sounds like the software this person wants already exists. A couple people mentioned AVISynth.
If they actually need something new, yeah they could champion adding the functionality to an existing project, but to refine that more I'd say find an existing project that serves the same *people* who would benefit from the new functionality. It's not just that the functionality of the software should be similar, you're looking for a group of users / programmers who would like to have the new functionality.
Time for bad analogy. A pita is very similar to a tortilla. If you wanted a new kind of pita sandwich, you wouldn't talk to a mexican restaurant. You're looking for *people* who would benefit from your idea.
At first it sounded like you had found a bad place to work or two. Then you mentioned VC funding. When a startup is trying to grab market share in a rapidly growing market, borrowing is the correct strategy. Management intentionally spends to get market share now and pays the debt back later, when the company is bigger. Borrowing includes technical debt.
For example, I worked for a company that was growing 80% per year, becoming a leader in a new business segment. They would quickly duct tape together some software that would allow them to expand into another chunk of the market, a chunk that will be worth $20 million in four years. Later, they can spend $1 million to go back and fix the duct tape mess. They net $19 million that way, incurring $1 million in technical debt to quickly grab $20 million of the market before competitors do.
Now, growth is slowing just a bit for that company and they want to go public, offer their stock on the stock exchange. To do that, they have to clean things up, be more stable. Over the years the technical people have used the term "technical debt" often to remind management it's there. Now management wants to start cleaning up the technical debt before going public and settling down just a bit.
I don't like the "rush it through with duct tape and baling wire" approach, but by understanding when that approach is correct I can tolerate it much better. I have to remember management *knows* they are creating a million dollar problem - in order to get a $10 million benefit. That helps me not get as frustrated. If understanding that doesn't do the trick for a particular developer, they'll probably enjoy an established, stable company better. General Mills, Walmart, and SC Johnson aren't looking at the next round of VC funding in 60 days, so they should plan IT projects on a 5-10 year time scale.
Ps: The FAA did recently issue some guidance clearing up the requirements for paper airplanes and birthday balloons. For a time, the wording of the proposed regulation would have required you to register a paper airplane before tossing it.
These are little plastic toys you can catch in your hand, so yes, I think it's a bit silly. I'm having trouble imagining how it could "cause expensive damage" - a baseball is more dangerous, denser and flies four times as fast. Should there be a law requiring all baseballs to be registered?
There's an obvious way to change a couple characters in thev regulation to make it much more sensible. Currently, toys weighing 255 grams or more have to be registered. 255 grams includes some designed to be flown indoors - toys that won't even damage your lamp. A more reasonable cutoff, which wouldn't encompass small toys, would be 1 Kg.
Note that people have been flying model aircraft for literally hundreds of years with very, very few problems.
Another issue with the current regulation is that it's illegal to fly a toy 6 feet off the ground in your backyard in most of the US, without contacting the nearest airstrips. You can't leave the ground, even a few inches, without talking to every airstrip within several miles, which typically means two or three of them (there are thousands of small airstrips and helipads in the US). Note you *can* fly a *kite* to 300 feet, but it's illegal to fly a toy helicopter at 6 feet. A more reasonable rule, which would again avoid ensnaring small toys in regulatory hassles, might require airstrip contact for items flown over 100 feet. Again, a baseball creates more risk to aircraft than does a little toy copter flying around the yard.
> And in what way is JavaScript reinventing threading - it's single-threaded!
As you know, a generic single-core cpu is also single-threaded. (Max 16 threads with 8 core cpu and hyperthreading). The operating system simulates running many threads at once. It's actually only running one thread at a time, switching between the two, below that level it's actually single-threaded (or has just a few cpu threads).
JavaScript / Emacscript does something similar - simulates running many tasks at once. In some implementations, it does so very poorly. In one particular implementation I had to use for several years, there were two underlying OS threads - one for network connections and UI interaction, one for everything else. That's possibly the stupidest possible division of labor - the part that should be fast, UI calls, had to wait for the slowest part (by far), the network connections. There is a reasonable argument that it would work a heck of a lot better if JavaScript exposed real threads, which have been implemented well by very smart people improving the implementations over many years. If Javascript exposed pthread_create() or some other interface to OS threads, "div.visibility = hidden" wouldn't have to wait for some unrelated, slow network connection to retry its DNS lookups.
There are also advantages to Javascript model of callbacks with a single real thread, just as there are disadvantages. There are reasons most languages expose real threads rather than offering *only* their own built-in simulation of multiple concurrent tasks - most languages expose threads because there are benefits of doing so.
The ideal may be a model where youb don't *need* to use real threads, a JavaScript-like model where the language wraps concurrent tasks in a pretty model, *and* clone() and fork() are available for the few times that you need them. Programming the Apache web server, writing Apache modules, is like that. It's callback-based and I don't recall offhand ever needing to create threads in an Apache module, I forked an external shared process for one module once. But that one time I needed to fork a process, I was able to.
For me, when I started working for the government, one problem I had was that it was hard to get used to everyone slacking off so much. Previously I worked for a company I own, so any slacking off hit me directly in theb pocketbook. It was frustrating when government employees would come into my office and chit-chat about nothing for an hour.
I eventually got used to it, relaxed, and enjoyed my stress-free job. The less-stressed approach didn't hurt productivity *as much* as I would have expected because it fostered communication between employees and didn't lead to rushing through work, cutting corners on quality because you're rushing. Our quality problems were instead due to lack of competence, because nobody got fired for failing to update their skills in 20 years.
Back in private sector now, I'm glad I had that experience. It reinforced something from working for companies I owned: I don't accept unrealistic deadlines, then deliver crappy trying to meet a deadline that doesn't allow quality work. I can and do tell the boss "no, I don't think we can do project X in a month, and I'm not going to promise you it'll be done in that time." So far, management has appreciated, or at least accepted, being told the truth. They know what "technical debt" is, and they don't want more of it. Actually, MOST of the time they don't want more technical debt. Sometimes, incurring technical debt makes sense, just like monetary debt (borrowing) sometimes makes sense. One instance springs to mind - we wanted to replace an annual contract with an in-house solution. It made sense to use duct tape and baling wire where needed to get the job done before the yearly cost was renewed, then replace the duct tape with bolts afterwards.
I don't even see that ground radar should be needed. One should able to look at previous projects in California and get a pretty good idea how many obstructions per mile is average. To estimate the cost, you don't need to know exactly how many boulders, how many pipes, etc - you can expect X obstructions per mile, on average.
Slashdot Mirror
> With email there's a trail, it can trivially be secured with GPG
And with DKIM signatures (needed to send email to Yahoo users) you can even prove that the message in evidence is actually what they sent - it hasn't been modified. Podesta, Donna Brazile, and Time Kaine found that out the hard way.
The framework isn't *just* a Perl, it was written for Linux. It checks /proc/cpuinfo, for example. Actually in some cases it uses *nix stuff where it should be using Perl. The other day I fixed this bit of "Perl":
$now = `date -s`;
Uhm, you mean this?
$now = time();
Lol.
The scenario you describe is something I fear, so just last night I worked to avoid it. Management is very concerned about some problems we had and they want to know what went wrong. Without going into detail, we had some bad code which caused a problem they noticed, problems that could affect revenue. I told them I would find the problem and report on how we can prevent a recurrence.
So this weekend I identified the problems in the code. I didn't start by telling top management the details of the bug; I my message to management starts with "last week, we paid some interest on our technical debt, previously known quality issues caused the situation. Recurrence of similar problems can be avoided by investing in correcting known issues in the code, rather than deferring this work as 'not high priority'. Specifically, the following known issues were involved in causing the problem, other issues may have also played a part. ..."
Management from the president down really want to make sure that problems like we had last week don't happen again. After hearing that the cause is various forms of technical debt, I expect management will decide we need to get rid of this nasty technical debt, to the extent that we can.
You insightfully identified the issue as "there is no one holding you accountable for paying back the former", part of my job, therefore, is to honestly inform them about the costs, so that the president of company holds middle managers responsible for addressing the issue. Another, similar, issue with tech debt is that it's normally not measured and doesn't appear on reports. Wise management, when they decide to incur tech debt (rush systems development) could write down a number for how much engineers estimate it will cost to a) maintain the less-robust system and b) eventually clean it up, making it more robust.
Has anyone used the new REST API they are replacing bulletins with? I've had trouble finding information about it, other than being told it's in no way RESTful.
> I think I'm gonna increase my MSFT position just in case.
Best of luck with that. I've always done mutual funds instead of trying to pick. I often discussed this with my best friend, who would always pick stocks. One day, in early 2008, he told me that rather than picking one company he had made a can't-lose buy: both Intel and AMD. Being the only two processor manufacturers with any significant market share, one of them would have to do well! Of course that was just about the time Android was released and most processor sales started to be ARM devices, neither Intel nor AMD.
Had I been more clever, I would have worked in a Netcraft joke and made it funny. Instead, I just accidentally typed Netcraft when I meant to type Statcounter.
I'm sure others have come up with slightly different numbers, but the point stands regardless. MS has gone from complete monopoly, what everyone used, to a minority - their market share of current *sales* is even less than the 38% statcounter shows. Yet they've managed to maintain and even grow revenue. Of course some of that is the fact that they actually make money on every Android device sold. :)
Which is amazing considering that a few years ago, 98% of people used their flagship product, Windows, while now only 38% of people do (Netcraft, 2016). They've done a really good job pivoting to maintain revenue while customers have dumped their traditional products en masse.
In 20 years, I've had exactly one occasion to run Linux stuff on Windows. I've had one other program I ran on Windows, that I can recall.
We have a framework on Linux, written mostly in Perl, which runs hundreds of small tools. We wanted to add a specific Windows-only tool to our system. So the g framework is installed under Cygwin on a few machines to run that one Windows tool.
No interpretation required. The FBI announced that she was without a doubt "very careless with classified information." That's a fact. The relevant crime is being "negligent" with classified information. That's a fact, no interpretation.
It's also a fact that in the same announcement, FBI director Comey, appointed by Obama, stated that other people would be prosecuted if they were similarly negligent. I'm not interpreting anything, that's what the FBI announced.
Did you play baccarat in Europe. There are three major varieties of baccarat. In North American casinos, Punto Banco is common. I understand in Punto Banco all players are playing against the house, similar to blackjack.
> having the average computer user familiar with using the command line
Perhaps. Having the average computer user exposing their scripts to internet is very dangerous. Which made it much easier when I learned, before the www was a thing.
The Director of the FBI, who is appointed by the President, said two things of import in his announcement:
A) Mrs. Clinton was "extremely careless" with classified information. (Being negligent with classified information is a federal crime).
B) He would not recommend prosecution. (Of the person who was about to become his boss, in all likelihood.)
So basically the FBI announced she was guilty, but they weren't going on record as recommending that the (expected) new boss be prosecuted.
Prosecutions for *perjury* are rare, for practical reasons. Less than 1% of people who clearly commit perjury are prosecuted for it.
> A huge number of professions would benefit from people being able to script up something to reduce their work load.
> There are companies still doing books in Excel by hand (not relying on any of Excel's built in functions).
That is a great example. In 1990-2000, VBA scripting was something that could be very useful to a lot of people. These days, the spreadsheet is probably in the cloud (on the internet), pulling data from some source on the internet. Having people who can almost barely code creating code for your business, including those web-enabled spreadsheets, will very likely end up with one of them making all your data from your spreadsheets available online.
As someone who learned to code in the 1980s, writing various types of macros and shell scripts that I ran on my computer, I feel for anyone starting to learn now. These days, most code is exposed to the web in some way, so it's attacked a hundred times per day. It's awfully hard to learn b safely in a business environment, when the smallest mistake will be exploited by hackers.
Huh?!?!? Are you saying the stuff she lied about was immaterial to the investigation? She was being being investigated for sending classified information via a non-secure email system. She said "I did not send material marked classified over non-secure email". How the hell is that immaterial to the subject of the investigation?
PS, as is often the case with the Clintons, her words were *very* carefully chosen to say one thing to anyone listening, while technically saying something completely different, in her mind. She said "I never sent material *marked* classified. She [unlawfully] removed the markings, in most cases (but not always, so it was a lie both ways).
> no problem at all with safe recreational use but calling it "medical marijuana" is just an insult to the intelligence of anyone with a functioning brain.
No problem, then. The term is used by and for potheads, not for people with a functioning brain.
Many years ago, I was into NORML and the marijuana legalization movement. (We called it "decriminalization".) I wrote some articles that were well received by my NORML peers. Looking back on what I wrote now, I think "what the hell? Wtf was I smoking when I wrote THIS? You'd have to be stoned out of your mind to believe any of this crap." Then I remember wtf I was smoking, and that my readers were indeed stoned out of their mind.
The federal perjury statute says a person is guilty of perjury if they lie in either of these two types of instances"
A) They've taken an oath in front of *any* court or competent *person* in any circumstance in which federal law allows an oath.
Or
B) Any written statement declaring "under penalty bof perjury", including a DMCA notice and certain customs forms.
Here's the actual text of the statute:
Whoeverâ" ...
(1) having taken an oath before a competent tribunal, officer, or person, in any case in which a law of the United States authorizes an oath to be administered, that he will testify, declare, depose, or certify truly, or that any written testimony, declaration, deposition, or certificate by him subscribed, is true, willfully and contrary to such oath states or subscribes any material matter which he does not believe to be true; or
(2) in any declaration, certificate, verification, or statement under penalty of perjury
* In a DMCA notice, the complainant swears under penalty lf perjury that they are the copyright holder or the copyright holder's representative. They do NOT swear under penalty of perjury that a jury won't later determine that it's fair use or any other issue of law.
I've been working in open source for 20 years, so I'll share my thoughts. I don't have statistics, and it would be hard to define statistics that aren't misleading. For example, counting the number of projects would count a script I wrote in two hours equally with the Linux kernel, or the Apache web server. So counting the number of projects doesn't make much sense.
A very common scenario is work done by a companies that use the software, but don't run the project. At my last job, I spent a lot of time developing Moodle, an open source ecampus software. The university I worked for was one of hundreds of schools and companies that use Moodle. I worked on features in Moodle that would be of use to the college I worked for. I suspect this model accounts for most of the hours spent working on open source, though possibly not most of the people or projects. Moodle was started as a master's thesis (or maybe phd).
I expect that the largest number of *projects* may be hobbyists and school-related (including masters and phd projects). Many, many people have released many, many small projects. Often, these are just enough to do the job, not as highly polished as something that has a marketing team trying to sell it. Sometimes they are well polished, but often not - if it works, that's often enough. These also tend to be projects that hobbyists *use*. Companies tend to sponsor projects used by companies, hobbysts tend to work on projects they use for their hobbies.
I would say that a minority of projects, but often big, important projects, are have a lot of development from a company selling a version of the software or support and related materials. Mysql and RedHat are good examples. These tend to include software used by companies. If thousands of companies are using some software, there is probably an opportunity to create a company providing support to them. Often, these projects started as hobbyist / school projects, and the company was founded after the software was successful.
Another set is formerly proprietary software that has been open sourced and is supported by the company. That would include Netscape/Firefox.
So I'd say the statistics depend on which statistics you look at. Most projects? Hobbyist. Most hours invested? Businesses that use the software. Most important? Often both developed by businesses that use it and a company that coordinates the project.
* After Moodle started being used by different schools, each contributing code, a company was set up to coordinate development, with a QA department, etc. The schools and companies who use Moodle develop features, the Moodle company makes sure that doesn't turn into chaos.
Based on other comments, it sounds like the software this person wants already exists. A couple people mentioned AVISynth.
If they actually need something new, yeah they could champion adding the functionality to an existing project, but to refine that more I'd say find an existing project that serves the same *people* who would benefit from the new functionality. It's not just that the functionality of the software should be similar, you're looking for a group of users / programmers who would like to have the new functionality.
Time for bad analogy. A pita is very similar to a tortilla. If you wanted a new kind of pita sandwich, you wouldn't talk to a mexican restaurant. You're looking for *people* who would benefit from your idea.
At first it sounded like you had found a bad place to work or two. Then you mentioned VC funding. When a startup is trying to grab market share in a rapidly growing market, borrowing is the correct strategy. Management intentionally spends to get market share now and pays the debt back later, when the company is bigger. Borrowing includes technical debt.
For example, I worked for a company that was growing 80% per year, becoming a leader in a new business segment. They would quickly duct tape together some software that would allow them to expand into another chunk of the market, a chunk that will be worth $20 million in four years. Later, they can spend $1 million to go back and fix the duct tape mess. They net $19 million that way, incurring $1 million in technical debt to quickly grab $20 million of the market before competitors do.
Now, growth is slowing just a bit for that company and they want to go public, offer their stock on the stock exchange. To do that, they have to clean things up, be more stable. Over the years the technical people have used the term "technical debt" often to remind management it's there. Now management wants to start cleaning up the technical debt before going public and settling down just a bit.
I don't like the "rush it through with duct tape and baling wire" approach, but by understanding when that approach is correct I can tolerate it much better. I have to remember management *knows* they are creating a million dollar problem - in order to get a $10 million benefit. That helps me not get as frustrated. If understanding that doesn't do the trick for a particular developer, they'll probably enjoy an established, stable company better. General Mills, Walmart, and SC Johnson aren't looking at the next round of VC funding in 60 days, so they should plan IT projects on a 5-10 year time scale.
Ps: The FAA did recently issue some guidance clearing up the requirements for paper airplanes and birthday balloons. For a time, the wording of the proposed regulation would have required you to register a paper airplane before tossing it.
These are little plastic toys you can catch in your hand, so yes, I think it's a bit silly. I'm having trouble imagining how it could "cause expensive damage" - a baseball is more dangerous, denser and flies four times as fast. Should there be a law requiring all baseballs to be registered?
There's an obvious way to change a couple characters in thev regulation to make it much more sensible. Currently, toys weighing 255 grams or more have to be registered. 255 grams includes some designed to be flown indoors - toys that won't even damage your lamp. A more reasonable cutoff, which wouldn't encompass small toys, would be 1 Kg.
Note that people have been flying model aircraft for literally hundreds of years with very, very few problems.
Another issue with the current regulation is that it's illegal to fly a toy 6 feet off the ground in your backyard in most of the US, without contacting the nearest airstrips. You can't leave the ground, even a few inches, without talking to every airstrip within several miles, which typically means two or three of them (there are thousands of small airstrips and helipads in the US). Note you *can* fly a *kite* to 300 feet, but it's illegal to fly a toy helicopter at 6 feet. A more reasonable rule, which would again avoid ensnaring small toys in regulatory hassles, might require airstrip contact for items flown over 100 feet. Again, a baseball creates more risk to aircraft than does a little toy copter flying around the yard.
I'm not the person you replied to, but ...
> And in what way is JavaScript reinventing threading - it's single-threaded!
As you know, a generic single-core cpu is also single-threaded. (Max 16 threads with 8 core cpu and hyperthreading). The operating system simulates running many threads at once. It's actually only running one thread at a time, switching between the two, below that level it's actually single-threaded (or has just a few cpu threads).
JavaScript / Emacscript does something similar - simulates running many tasks at once. In some implementations, it does so very poorly. In one particular implementation I had to use for several years, there were two underlying OS threads - one for network connections and UI interaction, one for everything else. That's possibly the stupidest possible division of labor - the part that should be fast, UI calls, had to wait for the slowest part (by far), the network connections. There is a reasonable argument that it would work a heck of a lot better if JavaScript exposed real threads, which have been implemented well by very smart people improving the implementations over many years. If Javascript exposed pthread_create() or some other interface to OS threads, "div.visibility = hidden" wouldn't have to wait for some unrelated, slow network connection to retry its DNS lookups.
There are also advantages to Javascript model of callbacks with a single real thread, just as there are disadvantages. There are reasons most languages expose real threads rather than offering *only* their own built-in simulation of multiple concurrent tasks - most languages expose threads because there are benefits of doing so.
The ideal may be a model where youb don't *need* to use real threads, a JavaScript-like model where the language wraps concurrent tasks in a pretty model, *and* clone() and fork() are available for the few times that you need them. Programming the Apache web server, writing Apache modules, is like that. It's callback-based and I don't recall offhand ever needing to create threads in an Apache module, I forked an external shared process for one module once. But that one time I needed to fork a process, I was able to.
For me, when I started working for the government, one problem I had was that it was hard to get used to everyone slacking off so much. Previously I worked for a company I own, so any slacking off hit me directly in theb pocketbook. It was frustrating when government employees would come into my office and chit-chat about nothing for an hour.
I eventually got used to it, relaxed, and enjoyed my stress-free job. The less-stressed approach didn't hurt productivity *as much* as I would have expected because it fostered communication between employees and didn't lead to rushing through work, cutting corners on quality because you're rushing. Our quality problems were instead due to lack of competence, because nobody got fired for failing to update their skills in 20 years.
Back in private sector now, I'm glad I had that experience. It reinforced something from working for companies I owned: I don't accept unrealistic deadlines, then deliver crappy trying to meet a deadline that doesn't allow quality work. I can and do tell the boss "no, I don't think we can do project X in a month, and I'm not going to promise you it'll be done in that time." So far, management has appreciated, or at least accepted, being told the truth. They know what "technical debt" is, and they don't want more of it. Actually, MOST of the time they don't want more technical debt. Sometimes, incurring technical debt makes sense, just like monetary debt (borrowing) sometimes makes sense. One instance springs to mind - we wanted to replace an annual contract with an in-house solution. It made sense to use duct tape and baling wire where needed to get the job done before the yearly cost was renewed, then replace the duct tape with bolts afterwards.
I don't even see that ground radar should be needed. One should able to look at previous projects in California and get a pretty good idea how many obstructions per mile is average. To estimate the cost, you don't need to know exactly how many boulders, how many pipes, etc - you can expect X obstructions per mile, on average.
It was Jimmy WALES. Ever wondered why he has no need to accept a salary for running Wikipedia?