> Well, duh :) Perl's still more popular than people think.
There is no way to define the word "popular" that makes this a true statement with regard to Perl 5 or any future development thereof shooting for backwards compatibility. -- I hate to be the negative nancy in this regard, but I seriously think that this is a cold and hard truth that is causing a lot of suffering because of people who fail to acknowledge it. (Disclosure: I work in a shop that forces me to do Perl, and I hate it with a passion).
One definition of "popular" would be: You ask programmers "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" [1]. 48.2% will then answer Python compared to 6.75% who will answer Ruby and 2.46% who will answer Perl.
Another definition of "popular" would be: Drilling down into those 2.46%, you ask them whether they love doing Perl or dread having to do Perl. 64% will answer they dread it [2]. This definitely agrees with my own experience working in a Perl-shop. Most people say they'd rather be doing something else. The company just feels that it doesn't make economic sense, so we're stuck with it.
For the other ones, I seriously suspect a case of Stockholm syndrome or something of the sort. -- Those would be the ones corresponding to the 0.86% (0.0246 x 0.36 = 0.00855) who say they do Perl and they actually like it.
The Perl code that's currently out there is literally sitting on top of an ecosystem that is rotting away beneath it [3]. For legacy code, the argument can sometimes be made that the situation is not bad enough yet to warrant moving away from Perl. But starting a new greenfield project in Perl 5 is, in my opinion, nothing short of professional malpractice.
So Perl is pretty much relegated to the hobbyist sphere, with Perl 5 maybe being of interest to retrocomputing aficionados. In that sense 80s-BASIC is very much the proper comparison class. Not modern-day Python or Ruby.
With Perl 6 / Raku not offering a viable migration path, one has to look at it the same way one would look at any other modern-day programming language upstart, with all the problems that entails (like lack of ecosystem, etc.)
Introspecting my own psychological experience now, I would go as far as to say that the open source developer community keeping Perl alive is perhaps the only group of people who truly meet the definition of giving the world something for free out of the goodness of their hearts (even in a way that ends up putting money in my own pockets), but who I actively dislike because of that. I feel like: If only Perl 5 would die a sudden death instead of this slow creeping demise, then, maybe, for me too this torture could finally come to an end.
FWIW, the Raku Programming Language nowadays *DOES* offer a valid migration path in the form of the Inline::Perl5 (https://raku.land/cpan:NINE/Inline::Perl5) module. This basically allows you to use all of CPAN that doesn't do source filters.
This allows you to gradually move your code into Raku, replacing Perl 5 modules by Raku ones as needed.
As we're about to reach the 2000 modules in the Raku ecosystem mark, it should be noted that many modules from CPAN are not needed, as they're builtins in the Raku Programming Language. And many CPAN modules have outlived their usefulness in any programming language.
Thanks for the pointer. I will look into this with great interest and get a discussion going within my company about whether this implies that we would want to start permitting Raku into our codebase. But I very much doubt that this permission will be granted in the end.
It's a widespread practice that companies provide laptops to contractors to compartmentalize the way they interact with the company's IT. But I'm really quite opposed to it.
At one point I had 3 sets of machines: Two different 14" laptops from two different clients and my own machines. At some point you simply run out of space on your desk and end up constantly either working on screens that are too small (14" really isn't enough to be productive), or plugging laptops in to and out of screens as you're context-switching. Carrying three laptops with you when you're travelling if you anticipate having to work for both clients during that timeframe is also not exactly my definition of great fun. And you end up duplicating a lot of effort around managing that IT, like tweaking settings the way you like them etc.
The argument "we own this laptop, so we can do with it whatever we want, including spying on you" is just not valid. They're either doing things that I'm okay with, in which case I'm okay doing it on my own hardware. Or they're doing things I'm opposed to, in which case I'm opposed to it no matter who owns the hardware.
Also: In many European countries, authorities are clamping down hard on practices whereby companies pass people off as contractors who really are employees. They usually work off of lists of criteria of what makes an employee, and if you fit too many of those criteria while, on paper, passing yourself off as a contractor, then you and your client can be in for a world of pain. One of the criteria that makes you look more like a contractor and less like an employee to the government is providing your own facilities like the computer you work with.
And, last but not least, it's just not a good way of dealing with the planet's resources.
I think there are absolutely a list of things that I don't want the company doing on my hardware, but I'm okay with on their hardware.
Off the top of my head, remote wipes/resets make sense. Frankly, I prefer the company has that option, just in case I lose my work laptop. Encryption should cover it, but I'll take the backup.
Compliance agents also have a legitimate reason to exist, but I don't want them on my personal PC. Some places maintain lists of allowed software (I think in part so they can track/inventory them for compliance stuff). I respect that they have the right to restrict what I install on my work laptop, but I reserve the right to install whatever I please on my own computer.
It would also not be insane for a company to do automated backups of company laptops to company servers. You want a way for Joe in marketing to get his data back when his cat pees on his laptop. I do not want all my personal documents on company servers.
This is really the thing people miss. It's a company laptop first and foremost and the right to privacy goes away.
The amount of compromising content we've seen and or found on investigations is mind blowing. No one needs that on a work computer. Keep your private life private from your employer.
The OP was about a contractor though. The way I think about somebody who is truly a contractor is that they are their own IT department, and their capabilities in the IT space should be at least on par with whatever the client's IT department enforces for in-house employees.
The above two comments however seem to be arguing from the viewpoint "this is just an individual person and any individual person surely needs babysitting by a big mighty corporate IT department because otherwise they can be expected to do stupid things like losing storage media with important data and not having backups, never doing updates, having their computers full of spyware, intermingling private stuff and work stuff from different clients in such a way that there's data leakage, etc. etc."
If you want to truly treat a contractor as a contractor, you should think about it as your IT needing to interface with their IT in such a way that it makes sense for both parties. And "here, use this laptop" is just frequently a bad solution from the point of view of the contractor's IT.
I also heavily object to the notion that any expectation of privacy goes away on a company laptop.
You can disagree with the expectation of privacy but it’s been held up in court multiple times that personal actions ok a corporate resource are not protected.
Ideologies and realties are different. If you care about personal data, don’t put it on the company. The company however has a huge liability with your personal data. I’ve mentioned else where I have dealt with issues of personal data becoming an issue for the company via blackmail, or in a couple cases, the company was legally required to report child pornography. So yeah, if you don’t want the company to know, don’t put it on their equipment. If you buy dedicated equipment for work, use it for work and work only. If you want to use your machine for Everything, that’s fine, but understand the risks and the lack of an expectation to privacy.
We're agreed that separation of work and private spheres is good practice.
But I'm not sure what country and what legal concept it is that you are referring to when you say "it's been held up in court multiple times that..." I'm based in Germany and have recently undergone GDPR-related training with a lawyer specializing in privacy law. In the training, the lawyer explained court cases that involved regrettable intermingling of work and private data in a company's IT. The result was that the law then started looking at that company's IT as being more akin to a telecommunication provider, with similar legal provisions coming into effect regarding telecommunication privacy.
Also: Anyone who lets their mind jump straight from "privacy" to "porn" is missing a big part of the picture of what privacy is all about. The way I think about it, it's a basic psychological need. Your psyche can be in a "public mode" where it assumes that any and all information flows emanating from you are out there for everyone to see and do with as they please. The result is that you have to put up huge amounts of self control which is psychologically exhausting. Therefore, the psyche seeks private spaces, where you don't need to control yourself as much because you know that nobody is watching.
The fight for privacy in the digital sphere is about ensuring that, just because our psyches are nowadays constantly linked to digital devices, this doesn't result in our psyches having to operate in "public mode" all the time.
It's about establishing clear delineations of who gets to receive what information flows relating to you and how they can potentially use that information against you.
For example: A company does time tracking through Excel sheets, but they also have IT security logs that keep track of people logging into and out of work machines. One day the company decides to run a project: They put the two data sources side by side and identify employees likely to be cheating on their time sheets. They fire the employees. ...this sets in motion a psychological effect in the remaining employees: They realize that they have a very poor understanding of what information the company's IT is collecting, and they don'T know how that information might one day be used against them. So all they can do is assume the worst. That means putting their psyches in "public mode" all the time, assuming the machine knows and sees everything, and the employer will use that information against employees at whatever time and in whatever manner suits them. The psychological damage done by this is precisely what we need to avoid!
And the GDPR will usually actually prohibit such things: The company's register of data processing activities will tie the security logs to the purpose of providing IT security. And it will tie the Excel timesheets to the purpose of time tracking. If you start using the security logs for time tracking purposes, you are using the data cross-purpose and are in violation of the GDPR and risk a hefty fine. This is a model usecase of what the GDPR is actually good for, and it clearly relates to protecting individuals' reasonable expectations of privacy in relation to their company's IT.
I still have two lying around. One of them was a 15” dell brick.
I had informed the client that I will be disposing of them when I’m back if they don’t handle it and that any and all third party liability well fall on the direct supervisor if he can’t organize the transfer.
Needlessly to say even me connecting them directly to the courier was not enough.
My guess is that the OP depends on the money otherwise he wouldn’t be asking for help. So either but a cheap laptop and then control it with barrier[1] from your main driver and don’t ask(because whatever you ask they will probably say no). Or let them ship theirs to you, but I’m willing to bet that it be worse than whatever second machine you get.
In the meantime I would suggest you look for a new client because judging from experience there is a lot more pain to come. I didn’t do it in time and ended up paying dearly for my lack of initiative on that front.
I have a dedicated laptop for a client that is in a room of my basement. I remote into it from my personal machine whenever I do work for them. Works very well!
How comfortable would you be if you learned that your cloud provider allowed a contractor in a random overseas country to connect to your production servers from a laptop on which he also read his personal email?
Would you like them to have some controls in place to prevent that?
Would you like that to be enforced consistently and audited?
Would you like them to provide you with a certification that their procedures to ensure that doesn’t happen meet some minimal standard?
Congratulations, you have invented ‘demanding SOC2 compliance from vendors’.
And the upshot of it is that some contractors have to put up with jumping through some hoops.
If you can afford to spend a bit of money on the problem, it's possible to use something like PiKVM or KVM-over-IP to just leave a stack of client laptops or mini-PCs out of the way somewhere and connect to them remotely in a reliable way, so you can reset the machine if the remote desktop software fails.
The ironic thing is that I work for a privacy-focused startup where such a practice is in total opposition to personal values held dearly by most people who work there. They claimed (and I assume that it's the truth) that this requirement was forced on them by the insurance industry. Apparently insurers are at the moment super-focused on cybersecurity threats and it's simply impossible for them to obtain general commercial insurance without having this in place. Going without the insurance means greatly diminished valuations and prospects for an exit.
So I installed the agent on a webserver that I have that has absolutely no data other than the static files that it serves to the web and that consequently are by definition public. So far they haven't noticed that it's not my actual work machine, and I expect that, with this being a mere box-ticking-exercise that they don't really care about and are on some level even opposed to, they have zero intention of taking it beyond "don't ask don't tell".
The thing I'm slightly worried about is that the agent logs logins and failed login-attempts. The problem is that employers who under normal circumstances never look at that data might suddenly get the idea of looking into it when employment disputes come up. So I'm a bit worried about creating an audit trail that basically says I never log in to my machine.
Maybe I need a cron job which, with a small amount of random variance, logs into the machine in the mornings and out again in the evening, but that would be crossing a line, legally speaking. With the current state of affairs I can plausibly plead negligence (I meant to install it on my personal device and just didn't notice that I was actually connected to the server when I hit "install"), but with an elaborate setup involving cron jobs and such, I'm clearly establishing that I'm acting in bad faith.
There is no way to define the word "popular" that makes this a true statement with regard to Perl 5 or any future development thereof shooting for backwards compatibility. -- I hate to be the negative nancy in this regard, but I seriously think that this is a cold and hard truth that is causing a lot of suffering because of people who fail to acknowledge it. (Disclosure: I work in a shop that forces me to do Perl, and I hate it with a passion).
One definition of "popular" would be: You ask programmers "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" [1]. 48.2% will then answer Python compared to 6.75% who will answer Ruby and 2.46% who will answer Perl.
Another definition of "popular" would be: Drilling down into those 2.46%, you ask them whether they love doing Perl or dread having to do Perl. 64% will answer they dread it [2]. This definitely agrees with my own experience working in a Perl-shop. Most people say they'd rather be doing something else. The company just feels that it doesn't make economic sense, so we're stuck with it.
For the other ones, I seriously suspect a case of Stockholm syndrome or something of the sort. -- Those would be the ones corresponding to the 0.86% (0.0246 x 0.36 = 0.00855) who say they do Perl and they actually like it.
The Perl code that's currently out there is literally sitting on top of an ecosystem that is rotting away beneath it [3]. For legacy code, the argument can sometimes be made that the situation is not bad enough yet to warrant moving away from Perl. But starting a new greenfield project in Perl 5 is, in my opinion, nothing short of professional malpractice.
So Perl is pretty much relegated to the hobbyist sphere, with Perl 5 maybe being of interest to retrocomputing aficionados. In that sense 80s-BASIC is very much the proper comparison class. Not modern-day Python or Ruby.
With Perl 6 / Raku not offering a viable migration path, one has to look at it the same way one would look at any other modern-day programming language upstart, with all the problems that entails (like lack of ecosystem, etc.)
Introspecting my own psychological experience now, I would go as far as to say that the open source developer community keeping Perl alive is perhaps the only group of people who truly meet the definition of giving the world something for free out of the goodness of their hearts (even in a way that ends up putting money in my own pockets), but who I actively dislike because of that. I feel like: If only Perl 5 would die a sudden death instead of this slow creeping demise, then, maybe, for me too this torture could finally come to an end.
[1] https://insights.stackoverflow.com/survey/2021#section-most-...
[2] https://insights.stackoverflow.com/survey/2021#section-most-...
[3] https://perlancar.wordpress.com/2019/08/01/dwindling-cpan-re...