I'm not convinced that things are any different today in productive software shops. However, the rate of failed projects (abandoned and replaced without reaching goals) is rather high these days, and the number of shops is higher too.
Most places I've worked had HR, but not this new corporate "HR" role whose job is to protect the company from the employee. HR's role can also be to be an expert in employee benefits, required paperwork, and vacation scheduling. They also can resolve pay mistakes and that sort of thing, freeing management from having to muck about in those literal "human resource management" tasks that bump up against a lot of paperwork that benefits from a specialist. If you have a manager who loves paperwork, you might not need HR nearly as soon. And if the paperwork is wrong, it may or may not even bite you later.
If tool choice is no longer up to the employee, that is something the employee should be deciding for themselves before applying to the job. If they're only trying to be a digital fry cook, they should not become attached to specific tools. If they're a valued professional, they should not be willing to throw away their proficiencies on somebody's whim; they should learn to say no, and just accept the jobs that they want to do. If I'm hired to be a database developer and I use generic portable tools that work with all the common databases, and then they want me to do web dev using their chosen tools, I'd expect to be told that my old job was ending and to be offered the new role; with the understanding that I might not want to accept it. I would not want to simply be told that my job was "changing" to a different specialty. Whereas if I was a janitor and I was told "we have too many janitors, we're transferring you to shipping" then it is usually a different thing because a janitor is not a sanitation engineer and is not a specialist. If the person's nametag said Sanitation Engineer, I'd want to handle it more diplomatically.
Even in the Bad Old Days where many had to buy special compilers, most people had their choice of editor. I really value the Freedom from that system that has developed. If new generations stop valuing software freedom... it won't reduce mine.;) They might think I'm stubborn, and then they might also find some problem that they're just not stubborn enough to get solved, because they could defer it and only cared about 80/20 this week, 80/20 next week.
I suspect there will be a large set of us that love systemd because it fixed a long list of technical shortcomings of SysV init, and who refuse to use Wayland because it removes a list of features we actually use, even if rarely.
systemd+X11 is my future, and I'm already living it.
I don't fear desktop environments sucking, most already do. They can suck as hard as they like, all they provide to me is a unified clipboard for copy/paste. I could ditch the DE and just use a window manager directly, and the only damage would be that once a week when I paste between applications that don't already use traditional unix pasting, I would have to paste to an intermediate app first.
VNC is fine, but it sucks bad compared to X if you're local and have enough bandwidth.
The thing is, with X networking you don't "forward the desktop." You open the application on a different machine's window system than the application is running on. So it is not the same use case as VNC. If you want the same thing on both, the application has to support the ability to open two windows with the same buffer, and the ability to open a window on another X server. emacs has that right in the pulldown menu, and that is my common use case; I can have the same buffer open at different computers in different parts of the room, and I can pace between them and type code into whichever is closer. And I don't have to squish a bunch of crap into a common screen size; or export a whole desktop, or have a bunch of extra window wrappings.
For normal use, it would look like:
$ DISPLAY="host.lan:0.0" myguiapplication
And now myguiapplication is running locally, with the (only) gui on host.lan's main X instance.
There are other ways to make similar stuff happen, but they have different pros and cons. A lot of people would buy some sort of consumer media appliance just to put content on a different screen. Some people want to remove this feature; others want to pay hundreds of dollars for similar capability.;)
Most of that is either not needed, or is in the pull-down menus on emacs and named as the normal thing, with the key combination listed next to it. There is no learning curve at all there; applications that have traditional discoverability of features don't cause a user to suffer for not having already memorized regex replace. Not everybody will need to shave seconds off of that to be productive. You don't list anything persuasive at all.
Indenting you only need to indent, you don't need to partial indent or un-indent to be efficient. In emacs, auto-indent is generally turned on, and it only takes one command to re-indent the whole file, or the selection if you made a selection first. Most people these days are required to use a single project-wide (or language-wide) indentation scheme, and there is no utility in not indenting consistently. I'm in the large set of emacs users that have tab mapped to indent-line. One of the few commands I use! I can just press tab while the cursor is anwhere in the line, and it indents correctly.
The "IDE increases your efficiency" line has always been false, and it can't even find specifics to claim that would be time savers. If you keep it down to, "IDE increases my efficiency," everybody always agreed that people like different tools.
From the perspective of people using CLI tools, IDE people can spend large amounts of time, hours even, figuring out how to do the things that can be typed into --options. But they don't subtract any of that time from the time savings they believe they receive. It is a failed argument, and it was already so 20 years ago.
People who think that users of other tools have a difficult time copying and pasting with their tools probably have not seen those tools used in a professional setting.
The language support features you describe are also used by emacs and vim users, often it requires installing a single support file.
Pretty sure some jobs are categorically out-of-reach for anyone with a criminal record.
Police officer and prison officer, for a start.
"D'oh!" I know cops and [other cops] can still work in that field after a conviction. You would too if you just read the small subset of news talking about fired or arrested cops; many have past convictions. You just imagine that it would be nice if cops were held to a high standard. That might not actually be the hiring process, though. You'd have to actually look into it to find out.
As for this situation, he doesn't have a criminal record. He not only hasn't been convicted, he hasn't even been accused. People who think they have evidence of a crime should get on the phone to the FBI right away. Because right now, he's not even a suspect and it is false and evil to lie and say that he does.
All of that said, back in `99 I remember a tech recruiter saying, "If you've got a murder conviction, I might not be able to find you a good programming job. But if it was only manslaughter, call me." These standards all depends on availability of workers, they're not actually based on the [imaginary] principles that people not involved in hiring often presume.
So? What is the name of the mental illness where you lash out and call people names, names that are not even designed to say anything other than "you have a medical problem, be cast out from society!" I neither have the illness you imagine, nor have I been cast out. You're a guy on the internet. What benefit do you perceive to get for yourself by "accusing" people of having medical problems? Is that likely to be a successful part of your treatment plan? Is it likely to lead to people valuing your contribution?
However, they really have produced a lot of good info....in spite of their own stupidity.
So its not brute fore, because the problems they are solving are real, its just the problem they are trying so solve isn't....which means.... they will never stop solving problems trying to solve it....
I'm as healthy as a loon, anyways. Real loons can't type, though. What health problems do you have that you're worried about my health? How special a snowflake do you have to be to diagnose illness via proximity to electrons that were in proximity to my electrons?
If somebody makes an personal, insulting attack on some random unfortunate on youtube, and I had a cough, would that make it less lame? How about less stupid?
What I want to know is, why is this group of talking apes so upset that that other group of apes is talking? Would it help if I rephrased it? Ah, AH AH AH AH AH AH AHAH AHHHHHHHHHHHHHH! *thump*thump*thump*
They were prepared. They waited until they had a higher than average pile of cases, and filed bankruptcy. Now they can "restructure" their debt, while maintaining business as usual.
And they even have a ride hailing app now.
The real lesson here is not to file bankruptcy frivolously. Save it for when you need it.
In many companies, a VP is a sort of executive assistant whose job is to listen to the P and then use the same tone and message and be the one actually talking to people all day that way.
In other companies, they're an actual executive with decision-making responsibilities.
Many companies employ both types of VP in different departments.
Almost no companies are willing to explain the actual duties of individual senior positions with the general public.
We don't what he did or didn't do, what advice he did or didn't give, or what people did or didn't want to hear.
All we know is, people say nasty things. All that actually teaches us is that there are nasty people in the world, and they're not going to wait for evidence or convictions before they try to apply a sentence, for example in this case they want to exile him from economic participation. They will fail spectacularly. They may or may not succeed in harming him in the way they intend in the meantime. But it will tarnish wikipedia substantially either way.
Go ahead and fork, it isn't a threat like you make it out to be. Either fork because you want to, or don't because you don't want to. Forking from sour grapes, nobody cares, but nobody wants to stop you either. It isn't odd he offered web space. He probably understands the licensing, and means it. You kinda understand, but not completely, because you don't think they mean it.
If they violate his employment rights by creating a hostile work environment and then firing him based on unproven accusation unrelated to the job and that predated his employment, then the resulting lawsuit might be one heck of a "public example" indeed.
It is one thing to wave your hands and hate on a guy whose name you saw next to some naughty words, it is a whole different thing to actually apply principles of worker rights in a real situation.
I think the argument isn't that he "can't be held to account for breaking the law" but rather that he hasn't been proven to have broken the law at all, and that it is very important to distinguish between an accusation and a conviction. I don't know what he did, and neither do you. Neither do the wikipedia editors. They do know that socially people said bad words next to his name. That is good enough for some people, not good enough for others. That it is good enough for wikipedia editors is no surprise to people who read the brackish waters of the talk pages.
If he hasn't been convicted of a crime, it violates his employment rights to try to blackball him based on unproven accusations.
Doesn't it bother you that you're proposing to clearly violate employment rights in order to punish unproven accusations of violating employment rights?
Same here. I also found that articles not being squatted on, I don't need to add references to make a simple edit; nobody checks them anyways.
It is vastly more likely that an edit is rolled back because somebody wants to control an article's message than that it is rolled back for being incorrect, biased, etc. Those all do also happen, no mistake about it. But they're less common than just mindless "no, I already re-wrote that section last year you can't reword it so that it matches the more authoritative article."
So now my policy is, I check the talk page; if there is any discussion in the last couple years, I put in my two cents there (or not) and don't try to actually edit anything. If an article is such a backwater that there is little or no talk text, then I just boldly correct whatever it is, and that correction will likely persist for years.
No, we won't agree to that. If there isn't a clear condition of his release that prohibits him from flying an airplane, and you're worried about it, the thing to do would be to agree to make a new rule that people convicted of that crime can't be airline pilots.
Society spent thousands of years reaching the current consensus that it is not appropriate for a mob to "maybe let's[sic] all agree" to ban people from jobs we don't want them to have.
What makes it petty squabbling nonsense is that it has nothing to do with his role at wikipedia. It is just base attack on an employee because people dislike them personally.
If what he did was illegal, they should be writing letters to the government, not trying to prevent him from ever working again.
Wikipedia needs to ban all these editors, because it is illegal to try to blackball somebody from an industry because you don't like what they did in a prior job somewhere else. They're attempting to overstep the authority of their roles in a way that violates the rights of the person they're trying to have cast out. Their removal is necessary to restore wikipedias reputation, because their actions are blatantly biased in a way that is caustic to open participation.
Maybe the guy is a [bad person], I don't know. I do know in this case that other [bad people] are attempting to violate his rights.
Right, you'd almost think from the media coverage that Colorado didn't have air taxi service, or helicopter rental generally.
Not spending time or money on planning and rule compliance certainly gives them an advantage, but how is it new, innovative, or likely to survive eventual competition?
If everybody did it that way, there would be no advantage. And if everybody tried to do it that way, we'd rediscover why the old rules were established without even having to look up the legislative record.
It is easy to measure if it is stubborness, or sticking with proficient tools.
You start from, why are you wanting them to change? Who is it about? Is their tool not actually proficient at the task they want to use it for, or is somebody else simply asserting that they should use a different tool?
Most of that we can answer just by looking at the claimed reasons for the change, without even having to accuse the old codger of being stubborn.
If git didn't work because he used nano, that would be a concern. But other tools don't actually care, and different people on the same team often do use different tools.
If a potential new employer doesn't want me to use the tools I'm proficient with, why exactly is he trying to choose me? And if the tools he's mandating are different than the ones I've investing my time in learning, why am I applying for that particular job? It seems almost built into the scenario that the employer is trying to hire somebody unqualified for cheap, and the employee is desperate and not an established professional.
It makes sense if an employer needs code to work in a particular compiler, but there is no reason it has to be written using a particular application. One of those is a reasonable professional expectation, the other is not.
And if somebody isn't productive with the tools they are proficient with, a different tool is unlikely to bridge that gap. And if it was, and they're a programmer of some sort, they'd really be expected to have discovered the bottleneck on their own.
As for languages, if the job is Perl and you're hiring a C guy, they're not going to be very efficient. I did 8 years of Perl before switching to Ruby for those tasks, and it isn't beginner friendly if you're working on existing applications or having to coordinate with multiple people. It is expert-friendly, though. Same for C. There is a category of programmer who believes themselves to be a magical being who can learn anything in a weekend, but none of them actually are. If he's going to add Perl, he needs to get started on that long before he agrees to write professional Perl code, or it will be full of implementation bugs.
The concept of worker specialization is a real thing; even if your specialty is that you're a generalist.
No, I've been using emacs for nearly 20 years and I'm not a "wizard" at all. I use less chords than I have fingers. The whole concept that programmer efficiency is based on things your GUI does for you is specious, as is the claim that emacs is difficult. You're not a crippled infant your first hour or week or year using emacs. You type in your code, it is pretty straightforwards. Learning features is for petty details like changing the colors of the syntax highlighting; things you learn over time, that may help a little, but mostly it is for personalization. All the normal stuff like search/replace is in the menu if you don't know the key combination. Almost all the integration is with command line tools and is therefore totally optional; you don't have to learn an emacs way of doing things, you just switch to a text terminal and run the command. If it is long or you have repeated options, you can learn how to store those options in a macro or key chord or shell alias; the solution to automate those things is essentially the same regardless of which tool you're using.
Vim obviously has a steeper learning curve because it is "mode based," and that isn't intuitive if you're not used to it. (that said, I do all my system admin editing in vim, not emacs; mode based editing shines on config files IMO)
If you sit down in front of emacs and never learn a single feature, it is notepad with syntax highlighting. How hard can that be? If there are complicated things it can do, that doesn't make it harder to use because those features do not step up and stand in your path; if you don't know about them, they basically don't exist. That isn't exactly what is implied by a steep learning curve.
Sed is obviously a much steeper curve. I don't recommend learning sed unless somebody is already spending a lot of time using a CLI. In that case, it is a time saver. There are GUI tools that do exactly the same thing, but ultimately the knowledge needed in both cases is almost identical; you have to learn the regex flavor your tool uses, and different tools will use different flavors. See also man 7 regex and man 1 perlre
These differences are mostly artificial. If you're used to an IDE, you might think emacs is hard, when really for you it is that the CLI is hard because you can't find anything. And if you're used to a CLI, then the GUI is hard because you often can't add options to a command, and it might not be obvious what feature steps in when you need to do something differently. Same problem on both sides; it is hard to find things when you're using an unfamiliar tool. The funny part about emacs being hard is that emacs isn't the part that people struggling with emacs are struggling with. They need to change screens and just use the normal CLI tool normally, and using emacs doesn't change that process at all for most users of it. Users who program in a lisp dialect probably use it for more things and code their automation into emacs directly, but that isn't the normal pattern.
In the context of TFQ, they're asking everybody regardless of background to use a new tool, because cloud.
You're just handwaving, you don't actually have a calculation of something where there would be a discrepancy. If you had that, we could check it right now.
And if it turns out that the people at LHC are not even trying to build a home-scale electrical generation device, then it would be highly unlikely that they're spending their days checking the work of tinkerers.;)
If you don't know, you don't know. If you didn't know, and said you did, that is a lie. You claim that these scientists are checking something that they themselves have not claimed to be checking.
And if you were to seek out more specifics, you would discover that science already knows that you can extract electricity from the physical structure of a magnet by constructing the right sort of mechanical device. The question these tinkerers are working on is, can you do it in the garage in a way that the Average Joe ends up paying less for electricity than he does now. And it is a known known that the scientists at LHC are not working on that problem. They're not average joes, and most of them are scientists not engineers. And the engineers are working on utility-scale ideas mostly. Pillaging the crystalline structure of magnets in novel ways is not likely to yield utility-level processes, but it could really mean "free energy" for people recycling magnets.
Just like a Joule Thief can mean "free energy" for people recycling disposable batteries. It just requires understanding that we mean "free as in beer."
No, if you're selectively labeling failed experiments that way you've already fallen off the wagon.
That many of his experiments were successful proves that he was using some sort of process with non-zero potential. If you thought the failed experiments were pseudoscience, you'd be shocked at the actual scientific process.
Failed experiments are not less science-y than successful experiments. And in modern times, lead has been converted successfully into gold. Newton redeemed!
If you read up on your Feynman, the "ether" is actually the closest to what quantum theory describes. According to that (the consensus theory), what we think of as "mass" is more like a bubble; like a negative pressure in an invisible medium. Different words than ether are used for historical reasons, but Feynman thought it was really funny the way people use the words.
The book Richard Feynman: A Life in Science explains it and gives the exact citations.
Slashdot Mirror
Thank you for the comment. It was not too long. :)
I'm not convinced that things are any different today in productive software shops. However, the rate of failed projects (abandoned and replaced without reaching goals) is rather high these days, and the number of shops is higher too.
Most places I've worked had HR, but not this new corporate "HR" role whose job is to protect the company from the employee. HR's role can also be to be an expert in employee benefits, required paperwork, and vacation scheduling. They also can resolve pay mistakes and that sort of thing, freeing management from having to muck about in those literal "human resource management" tasks that bump up against a lot of paperwork that benefits from a specialist. If you have a manager who loves paperwork, you might not need HR nearly as soon. And if the paperwork is wrong, it may or may not even bite you later.
If tool choice is no longer up to the employee, that is something the employee should be deciding for themselves before applying to the job. If they're only trying to be a digital fry cook, they should not become attached to specific tools. If they're a valued professional, they should not be willing to throw away their proficiencies on somebody's whim; they should learn to say no, and just accept the jobs that they want to do. If I'm hired to be a database developer and I use generic portable tools that work with all the common databases, and then they want me to do web dev using their chosen tools, I'd expect to be told that my old job was ending and to be offered the new role; with the understanding that I might not want to accept it. I would not want to simply be told that my job was "changing" to a different specialty. Whereas if I was a janitor and I was told "we have too many janitors, we're transferring you to shipping" then it is usually a different thing because a janitor is not a sanitation engineer and is not a specialist. If the person's nametag said Sanitation Engineer, I'd want to handle it more diplomatically.
Even in the Bad Old Days where many had to buy special compilers, most people had their choice of editor. I really value the Freedom from that system that has developed. If new generations stop valuing software freedom... it won't reduce mine. ;) They might think I'm stubborn, and then they might also find some problem that they're just not stubborn enough to get solved, because they could defer it and only cared about 80/20 this week, 80/20 next week.
I suspect there will be a large set of us that love systemd because it fixed a long list of technical shortcomings of SysV init, and who refuse to use Wayland because it removes a list of features we actually use, even if rarely.
systemd+X11 is my future, and I'm already living it.
I don't fear desktop environments sucking, most already do. They can suck as hard as they like, all they provide to me is a unified clipboard for copy/paste. I could ditch the DE and just use a window manager directly, and the only damage would be that once a week when I paste between applications that don't already use traditional unix pasting, I would have to paste to an intermediate app first.
VNC is fine, but it sucks bad compared to X if you're local and have enough bandwidth.
The thing is, with X networking you don't "forward the desktop." You open the application on a different machine's window system than the application is running on. So it is not the same use case as VNC. If you want the same thing on both, the application has to support the ability to open two windows with the same buffer, and the ability to open a window on another X server. emacs has that right in the pulldown menu, and that is my common use case; I can have the same buffer open at different computers in different parts of the room, and I can pace between them and type code into whichever is closer. And I don't have to squish a bunch of crap into a common screen size; or export a whole desktop, or have a bunch of extra window wrappings.
For normal use, it would look like:
$ DISPLAY="host.lan:0.0" myguiapplication
And now myguiapplication is running locally, with the (only) gui on host.lan's main X instance.
There are other ways to make similar stuff happen, but they have different pros and cons. A lot of people would buy some sort of consumer media appliance just to put content on a different screen. Some people want to remove this feature; others want to pay hundreds of dollars for similar capability. ;)
Most of that is either not needed, or is in the pull-down menus on emacs and named as the normal thing, with the key combination listed next to it. There is no learning curve at all there; applications that have traditional discoverability of features don't cause a user to suffer for not having already memorized regex replace. Not everybody will need to shave seconds off of that to be productive. You don't list anything persuasive at all.
Indenting you only need to indent, you don't need to partial indent or un-indent to be efficient. In emacs, auto-indent is generally turned on, and it only takes one command to re-indent the whole file, or the selection if you made a selection first. Most people these days are required to use a single project-wide (or language-wide) indentation scheme, and there is no utility in not indenting consistently. I'm in the large set of emacs users that have tab mapped to indent-line. One of the few commands I use! I can just press tab while the cursor is anwhere in the line, and it indents correctly.
The "IDE increases your efficiency" line has always been false, and it can't even find specifics to claim that would be time savers. If you keep it down to, "IDE increases my efficiency," everybody always agreed that people like different tools.
From the perspective of people using CLI tools, IDE people can spend large amounts of time, hours even, figuring out how to do the things that can be typed into --options. But they don't subtract any of that time from the time savings they believe they receive. It is a failed argument, and it was already so 20 years ago.
People who think that users of other tools have a difficult time copying and pasting with their tools probably have not seen those tools used in a professional setting.
The language support features you describe are also used by emacs and vim users, often it requires installing a single support file.
Pretty sure some jobs are categorically out-of-reach for anyone with a criminal record.
Police officer and prison officer, for a start.
"D'oh!" I know cops and [other cops] can still work in that field after a conviction. You would too if you just read the small subset of news talking about fired or arrested cops; many have past convictions. You just imagine that it would be nice if cops were held to a high standard. That might not actually be the hiring process, though. You'd have to actually look into it to find out.
As for this situation, he doesn't have a criminal record. He not only hasn't been convicted, he hasn't even been accused. People who think they have evidence of a crime should get on the phone to the FBI right away. Because right now, he's not even a suspect and it is false and evil to lie and say that he does.
All of that said, back in `99 I remember a tech recruiter saying, "If you've got a murder conviction, I might not be able to find you a good programming job. But if it was only manslaughter, call me." These standards all depends on availability of workers, they're not actually based on the [imaginary] principles that people not involved in hiring often presume.
So? What is the name of the mental illness where you lash out and call people names, names that are not even designed to say anything other than "you have a medical problem, be cast out from society!" I neither have the illness you imagine, nor have I been cast out. You're a guy on the internet. What benefit do you perceive to get for yourself by "accusing" people of having medical problems? Is that likely to be a successful part of your treatment plan? Is it likely to lead to people valuing your contribution?
However, they really have produced a lot of good info....in spite of their own stupidity.
So its not brute fore, because the problems they are solving are real, its just the problem they are trying so solve isn't....which means.... they will never stop solving problems trying to solve it....
Interestingly, the same is true of science.
I'm as healthy as a loon, anyways. Real loons can't type, though. What health problems do you have that you're worried about my health? How special a snowflake do you have to be to diagnose illness via proximity to electrons that were in proximity to my electrons?
If somebody makes an personal, insulting attack on some random unfortunate on youtube, and I had a cough, would that make it less lame? How about less stupid?
What I want to know is, why is this group of talking apes so upset that that other group of apes is talking? Would it help if I rephrased it? Ah, AH AH AH AH AH AH AHAH AHHHHHHHHHHHHHH! *thump*thump*thump*
They were prepared. They waited until they had a higher than average pile of cases, and filed bankruptcy. Now they can "restructure" their debt, while maintaining business as usual.
And they even have a ride hailing app now.
The real lesson here is not to file bankruptcy frivolously. Save it for when you need it.
In many companies, a VP is a sort of executive assistant whose job is to listen to the P and then use the same tone and message and be the one actually talking to people all day that way.
In other companies, they're an actual executive with decision-making responsibilities.
Many companies employ both types of VP in different departments.
Almost no companies are willing to explain the actual duties of individual senior positions with the general public.
We don't what he did or didn't do, what advice he did or didn't give, or what people did or didn't want to hear.
All we know is, people say nasty things. All that actually teaches us is that there are nasty people in the world, and they're not going to wait for evidence or convictions before they try to apply a sentence, for example in this case they want to exile him from economic participation. They will fail spectacularly. They may or may not succeed in harming him in the way they intend in the meantime. But it will tarnish wikipedia substantially either way.
Go ahead and fork, it isn't a threat like you make it out to be. Either fork because you want to, or don't because you don't want to. Forking from sour grapes, nobody cares, but nobody wants to stop you either. It isn't odd he offered web space. He probably understands the licensing, and means it. You kinda understand, but not completely, because you don't think they mean it.
If they violate his employment rights by creating a hostile work environment and then firing him based on unproven accusation unrelated to the job and that predated his employment, then the resulting lawsuit might be one heck of a "public example" indeed.
It is one thing to wave your hands and hate on a guy whose name you saw next to some naughty words, it is a whole different thing to actually apply principles of worker rights in a real situation.
I think the argument isn't that he "can't be held to account for breaking the law" but rather that he hasn't been proven to have broken the law at all, and that it is very important to distinguish between an accusation and a conviction. I don't know what he did, and neither do you. Neither do the wikipedia editors. They do know that socially people said bad words next to his name. That is good enough for some people, not good enough for others. That it is good enough for wikipedia editors is no surprise to people who read the brackish waters of the talk pages.
If he hasn't been convicted of a crime, it violates his employment rights to try to blackball him based on unproven accusations.
Doesn't it bother you that you're proposing to clearly violate employment rights in order to punish unproven accusations of violating employment rights?
Same here. I also found that articles not being squatted on, I don't need to add references to make a simple edit; nobody checks them anyways.
It is vastly more likely that an edit is rolled back because somebody wants to control an article's message than that it is rolled back for being incorrect, biased, etc. Those all do also happen, no mistake about it. But they're less common than just mindless "no, I already re-wrote that section last year you can't reword it so that it matches the more authoritative article."
So now my policy is, I check the talk page; if there is any discussion in the last couple years, I put in my two cents there (or not) and don't try to actually edit anything. If an article is such a backwater that there is little or no talk text, then I just boldly correct whatever it is, and that correction will likely persist for years.
No, we won't agree to that. If there isn't a clear condition of his release that prohibits him from flying an airplane, and you're worried about it, the thing to do would be to agree to make a new rule that people convicted of that crime can't be airline pilots.
Society spent thousands of years reaching the current consensus that it is not appropriate for a mob to "maybe let's[sic] all agree" to ban people from jobs we don't want them to have.
Point being, nobody made you bridge-keeper.
What makes it petty squabbling nonsense is that it has nothing to do with his role at wikipedia. It is just base attack on an employee because people dislike them personally.
If what he did was illegal, they should be writing letters to the government, not trying to prevent him from ever working again.
Wikipedia needs to ban all these editors, because it is illegal to try to blackball somebody from an industry because you don't like what they did in a prior job somewhere else. They're attempting to overstep the authority of their roles in a way that violates the rights of the person they're trying to have cast out. Their removal is necessary to restore wikipedias reputation, because their actions are blatantly biased in a way that is caustic to open participation.
Maybe the guy is a [bad person], I don't know. I do know in this case that other [bad people] are attempting to violate his rights.
Right, you'd almost think from the media coverage that Colorado didn't have air taxi service, or helicopter rental generally.
Not spending time or money on planning and rule compliance certainly gives them an advantage, but how is it new, innovative, or likely to survive eventual competition?
If everybody did it that way, there would be no advantage. And if everybody tried to do it that way, we'd rediscover why the old rules were established without even having to look up the legislative record.
That is already banned in most States. She can do it at home because she lives on Putin's back porch.
The answers to your questions were already well established before you were born.
A related question, also answered long before you were born; if my neighbor is operating a helicopter outside my window, why can't I just shoot him?
I'll give you a hint, the answers are directly related and joined together at the hip.
It is easy to measure if it is stubborness, or sticking with proficient tools.
You start from, why are you wanting them to change? Who is it about? Is their tool not actually proficient at the task they want to use it for, or is somebody else simply asserting that they should use a different tool?
Most of that we can answer just by looking at the claimed reasons for the change, without even having to accuse the old codger of being stubborn.
If git didn't work because he used nano, that would be a concern. But other tools don't actually care, and different people on the same team often do use different tools.
If a potential new employer doesn't want me to use the tools I'm proficient with, why exactly is he trying to choose me? And if the tools he's mandating are different than the ones I've investing my time in learning, why am I applying for that particular job? It seems almost built into the scenario that the employer is trying to hire somebody unqualified for cheap, and the employee is desperate and not an established professional.
It makes sense if an employer needs code to work in a particular compiler, but there is no reason it has to be written using a particular application. One of those is a reasonable professional expectation, the other is not.
And if somebody isn't productive with the tools they are proficient with, a different tool is unlikely to bridge that gap. And if it was, and they're a programmer of some sort, they'd really be expected to have discovered the bottleneck on their own.
As for languages, if the job is Perl and you're hiring a C guy, they're not going to be very efficient. I did 8 years of Perl before switching to Ruby for those tasks, and it isn't beginner friendly if you're working on existing applications or having to coordinate with multiple people. It is expert-friendly, though. Same for C. There is a category of programmer who believes themselves to be a magical being who can learn anything in a weekend, but none of them actually are. If he's going to add Perl, he needs to get started on that long before he agrees to write professional Perl code, or it will be full of implementation bugs.
The concept of worker specialization is a real thing; even if your specialty is that you're a generalist.
No, I've been using emacs for nearly 20 years and I'm not a "wizard" at all. I use less chords than I have fingers. The whole concept that programmer efficiency is based on things your GUI does for you is specious, as is the claim that emacs is difficult. You're not a crippled infant your first hour or week or year using emacs. You type in your code, it is pretty straightforwards. Learning features is for petty details like changing the colors of the syntax highlighting; things you learn over time, that may help a little, but mostly it is for personalization. All the normal stuff like search/replace is in the menu if you don't know the key combination. Almost all the integration is with command line tools and is therefore totally optional; you don't have to learn an emacs way of doing things, you just switch to a text terminal and run the command. If it is long or you have repeated options, you can learn how to store those options in a macro or key chord or shell alias; the solution to automate those things is essentially the same regardless of which tool you're using.
Vim obviously has a steeper learning curve because it is "mode based," and that isn't intuitive if you're not used to it. (that said, I do all my system admin editing in vim, not emacs; mode based editing shines on config files IMO)
If you sit down in front of emacs and never learn a single feature, it is notepad with syntax highlighting. How hard can that be? If there are complicated things it can do, that doesn't make it harder to use because those features do not step up and stand in your path; if you don't know about them, they basically don't exist. That isn't exactly what is implied by a steep learning curve.
Sed is obviously a much steeper curve. I don't recommend learning sed unless somebody is already spending a lot of time using a CLI. In that case, it is a time saver. There are GUI tools that do exactly the same thing, but ultimately the knowledge needed in both cases is almost identical; you have to learn the regex flavor your tool uses, and different tools will use different flavors. See also man 7 regex and man 1 perlre
These differences are mostly artificial. If you're used to an IDE, you might think emacs is hard, when really for you it is that the CLI is hard because you can't find anything. And if you're used to a CLI, then the GUI is hard because you often can't add options to a command, and it might not be obvious what feature steps in when you need to do something differently. Same problem on both sides; it is hard to find things when you're using an unfamiliar tool. The funny part about emacs being hard is that emacs isn't the part that people struggling with emacs are struggling with. They need to change screens and just use the normal CLI tool normally, and using emacs doesn't change that process at all for most users of it. Users who program in a lisp dialect probably use it for more things and code their automation into emacs directly, but that isn't the normal pattern.
In the context of TFQ, they're asking everybody regardless of background to use a new tool, because cloud.
You're just handwaving, you don't actually have a calculation of something where there would be a discrepancy. If you had that, we could check it right now.
And if it turns out that the people at LHC are not even trying to build a home-scale electrical generation device, then it would be highly unlikely that they're spending their days checking the work of tinkerers. ;)
If you don't know, you don't know. If you didn't know, and said you did, that is a lie. You claim that these scientists are checking something that they themselves have not claimed to be checking.
And if you were to seek out more specifics, you would discover that science already knows that you can extract electricity from the physical structure of a magnet by constructing the right sort of mechanical device. The question these tinkerers are working on is, can you do it in the garage in a way that the Average Joe ends up paying less for electricity than he does now. And it is a known known that the scientists at LHC are not working on that problem. They're not average joes, and most of them are scientists not engineers. And the engineers are working on utility-scale ideas mostly. Pillaging the crystalline structure of magnets in novel ways is not likely to yield utility-level processes, but it could really mean "free energy" for people recycling magnets.
Just like a Joule Thief can mean "free energy" for people recycling disposable batteries. It just requires understanding that we mean "free as in beer."
No, if you're selectively labeling failed experiments that way you've already fallen off the wagon.
That many of his experiments were successful proves that he was using some sort of process with non-zero potential. If you thought the failed experiments were pseudoscience, you'd be shocked at the actual scientific process.
Failed experiments are not less science-y than successful experiments. And in modern times, lead has been converted successfully into gold. Newton redeemed!
If you read up on your Feynman, the "ether" is actually the closest to what quantum theory describes. According to that (the consensus theory), what we think of as "mass" is more like a bubble; like a negative pressure in an invisible medium. Different words than ether are used for historical reasons, but Feynman thought it was really funny the way people use the words.
The book Richard Feynman: A Life in Science explains it and gives the exact citations.