Then you have those types who put their machine into hibernate/sleep with 100+ Chrome tabs open and never do a full boot ritual. Boggles my mind that people do that.
Then you have those types who put their machine into hibernate/sleep with 100+ Chrome tabs open and never do a full boot ritual. Boggles my mind that people do that.
When we looked at his PC to see if there was anything useful from the project, his browser had around a thousand tabs open. Probably 80% of them were duplicates of other tabs, linking to the same couple stack overflow and C# sites for really basic stuff. The other 20% were... definitely "private stuff".
There's a huge red flag. "Private stuff" (embarrassing or otherwise) shouldn't be on company machines in the first place.
However if anyone touches my computer: don't you dare f*%king touch my private key.
(ditto for my browsers sessions database, google cloud credentials directory etc;)
I'm paranoid about it, but not enough to buy a yubikey, apparently.
Touch the computer, sure, but please don’t touch the screen with your filthy grease fingers.
But if those keys (or passwords, etc.) are generated for work purposes, I consider them to be as much company property as the machine itself, so I'm no more protective of them than I am of any other sensitive company data.
How do you feel about giving your colleague your password?
My personal opinion is that I can hold someone legally culpable if their account does something like leak financial information; you have a professional responsibility to secure your account from absolutely everyone.
Administrators acting on your account must of course be heavily logged and audited, which is the case.
I usually don't, mostly just out of good security habits, but also because most employers specifically prohibit doing that.
Almost always, your colleague can be given his own access to whatever the password is for anyway. If that's not possible, then I'll share the password and change it immediately after my colleague doesn't need access anymore.
> you have a professional responsibility to secure your account from absolutely everyone.
I agree -- that's part of treating credentials the same way as all other sensitive company data. But it's still my employer's data, not mine.
If I quit the company or if my supervisor wants to see the contents of my machine, I'm fine with that. The machine and everything on it belongs to the company anyway.
They tie to your identity, thus you must not treat them the same as company secrets, they are professional personal secrets which should not be disclosed or allowed to fall into anyone elses hands (less they be revoked and cycled).
It's not just good security posture it could affect your career quite badly or lead to legal issues.
> thus you must not treat them the same as company secrets, they are professional personal secrets
They are company secrets that are tied to my identity. The company owns those secrets, not me. Just like my keycard to get into the building.
I think given the context of the thread (don't touch my secrets), saying that you don't have anything you would consider confidential towards your employer or colleagues is a direct contradiction to what I stated.
That's why I'm "arguing" because my employer/colleagues should not have access to my private key, ever.
There are several very legitimate times when my employer needs to have access to my keys. If I'm leaving the company, for an obvious instance.
But my core point is that such keys/passwords aren't really mine, they're the company's and in the end, the company gets to decide what I'm to do with them.
I think the building access keycard is a perfect analogy. I'd never let anyone borrow mine on my own volition, but if the company wants to retrieve it from me, that's their prerogative. It's theirs, after all.
There are exceptions but the circumstances where an employer would need to retrieve my keys without my assistance are extremely rare and in those instances it’s unlikely I’d still be an employee anyway.
The handing of the keycard is necessary to ensure it's destroyed and can't be used as a "proof" you work somewhere (most access cards these days have your name, face and the company logo printed on the front).
The keycard will be removed from the access list to the building even when it's destroyed, they're not considered reusable by most companies.
Your private key is not reusable, it should be destroyed and revoked from all system when you leave a company.
Aside from a third party attacker (which is well-covered by my normal practices), that's a threat model that I'm personally not worried about at all, really. In part because I've never seen or heard of that happening and in part because if it did, I am confident that there are enough records to be able to prove it.
By default this should be what is happening on all but the most ephemeral of machines/testing platforms/etc. And even then if its a formal testing system it should probably be integrated too.
Directory service integration BTW is the one feature that clearly delineates enterprise products from the rest.
I'm fine with that, but I still will not share my passwords. I'd be happy to reset the passwords for them if they can't access the data by other means, but as another commenter pointed out, the fact that anything needs to be recovered from my^H^H not my laptop indicates mistakes were made.
On one of my largest projects the IT dept made bulk orders for hardware and doled them out to new hires. 18 months into our new project someone’s hard drive died.
Everyone acted like his dog died. I said no problem let’s go through the onboarding docs. The longest step by far was that the company mandated Whole Disk Encryption but IT hadn’t put it in their old inventory yet. So that was 2/3 of setup time. We found some issues with the docs and fixed them.
Every two to four weeks that summer, someone else’s drive would go. You see, we got all of these machines from the same production run. So the hard drives came from the same production run, which was apparently faulty. The process got a little faster as we went. By the end of the summer it was my turn, and people still looked at me like I needed condolences. I got a faster machine for a few hours worth of work. I’m not sad. All my stuff was in the network already. I lost a couple hours’ of work, tops.
I thought this was a typo at first. Love this as an engineering koan.
3 -> 2 means you now only need two people to be hit by buses to ruin your project.
There are very few machines in the world that are actually mission critical, and you might not be able to do that (although for them, you can probably switch components with it still running). Anybody else, you are just betting your company on the lack of fires, hardware failure, etc.
With today’s software for managing corporate machines, and corporate VPN with network security and firewalls abound, anything and everything can be seen.
I have a joke Wi-Fi name that I’ve even considered changing (or at least create a guest network) just to be safe. It’s likely overboard, but I like the idea of just mailing my laptop if I change companies, and no worries at all
Sounds very american. In European working culture if you don't show up for two weeks people will be worried that something happened to you and try to work it out with you. This type of all or nothing reaction is a bit sporadic imo.
Yeah, it's not like that part of the story was condensed and might have left out a bunch of details that weren't important to the story. So let's give OP a hard time and make judgements about a situation for which we have not even the slightest bit of context.
(For what it's worth, I'm American, and I disagree with your assessment. We don't know how long the person was given to make progress, and we don't know what was communicated. To conclude that a two-week period without a commit represents the entire period between the start of the poor performance and the termination is, well, a bit out of the blue.)
When I was hired I was told he was a problematic hire, that hadn't produced anything for long before my arrival. It was basically "We already know we're going to probably have to let him go but if you want to try to work around it, be my guest". I did try to go in with no judgments, as I always do, but he refused help, and refused to even let anyone look over his shoulder and find why this task was taking an order of magnitude too long.
If the OS and hardware drivers properly support sleep, you almost never need to do otherwise (except to install a new kernel driver or similar).
In macOS for example it hasn't been the case that you need reboot in your regular OS use for over 10+ years.
The "100+ Chrome tabs" or whatever mean nothing. They're paged out when not directly viewed anyway, and if you close just Chrome (not reboot the OS) the memory will be freed in any case...
That's like the biggest of big IFs.
I once had my work PC unhibernate and not pop up the login box. The computer appeared to be running normally otherwise; I just couldn't log in, and I had to tap the power button to shut it down. This stuck in my mind due to its rarity.
Can't remember ever having a serious issue on macOS. A couple of my programs sometimes don't survive the sleep/wake cycle, but it's intermittent, and I'm always in the middle of something else when it happens. I've never lost any meaningful work.
> Can't remember ever having a serious issue on macOS.
macos is fine for the most part, but there are some edge cases, such as some sketchy corporate required "security software" that eats up kernel memory or cpu for some unknown reason, a reboot can fix performance issues therealso if you are a dev and apps (like xcode, android studio etc) fill your drive with cache files* or have weird background daemons that eat up cpu, at the least a logout/login (or a reboot) can fix some of those eierd things
you could manually delete them without a reboot but ymmv
I have actually found both Windows and macOS generally pretty good if you leave them running for weeks at a time, but it's one of those things that's best done only if you really need it (and can accept a non-zero chance of something going wrong). They're not so very good that I'd actually recommend doing it routinely. A reboot every 1 or 2 weeks massively reduces the chance of weird stuff happening.
Why?
It boggles my mind that you'd reboot needlessly. My uptime is usually in the hundreds of days.
Sleep is good: I just close the lid. Next time I open the lid it immediately picks up where I left off. Why on earth would you want any other behaviour?
I close down my laptop when I'm moving around or when I leave it somewhere while I'm in another part of the building.
At work, however, I have to use Windows. In that case, I shut it down at the end of every workday, in part because that prevents weird issues Windows tends to develop when running too long.
Mostly, though, it's because of those damned forced updates. Since I can't trust Windows to not reboot itself at any random point in time, having the habit of shutting down at the end of the day at least ensures that I won't accidentally lose my state overnight or over the weekend.
If you don't/won't/can't use the group policy editor, I got a lot of mileage out of hibernating the PC and powering it off at the mains. You can't leave it running something overnight, but you can at least quickly get back to exactly where you left things the previous day.
(Powering it off at the mains ensures that even if you have a device connected that could wake the PC up - thus putting your computer in a state where WIndows Update can reboot it - it can't. You can turn this feature off on a per-device basis with powercfg, but then one day you'll plug something new in and leave it plugged in and it'll wake the PC up while you're away and Windows Update will do its thing.)
What are you using Windows Vista? I run about a dozen windows machines, half of them are VMs and none of them need to be rebooted regularly. Average uptime is over 40 days, and I only reboot when there's a big update. Windows becoming unstable entirely depends on the 3rd party software you install on it. Don't install crapware, you won't have a crap experience.
Your luck is not good security policy. When I was getting started with Linux in 1992 and only intermittently connected to the Internet via dial-up, I celebrated long uptimes. Now that I do daily banking and other activities on a machine continuously connected to the Internet, uptimes longer than the interval between kernel security updates is just irresponsible behavior.
I would prefer to not have to reboot. I know that is not the world we live in. The stability of the kernel is no longer the reason to think about uptime.
I don't care that you have nothing of value connected to the Internet. I am objecting to the advice about not rebooting.
A couple of times I've discovered I've forgotten to set stuff to auto-run on login, or things turn out to have lost their settings, or stuff doesn't work for whatever reason - I'd much rather discover this at a time of my own choosing!
:( I only reboot when my machine freezes or when updates require a reboot. I did a lot of on-call in my life and I saved tons of time by leaving everything open exactly as I left it during the day.
~> w
11:19 up 18 days, 17:03, 9 users, load averages: 3.87 2.96 2.39I logged into a firewalled Windows VM on EC2 that’s been running an internal micro service that was acting up and it caught my eye that task manager showed an uptime of 6 days making my mind immediately think it might be a bug caused by the recent reboot or perhaps the update that triggered it.
It turns out no reboot had taken place and in fact, the uptime counter had merely rolled over - and not for the first time! Bug was unrelated to the machine and it’s still (afaik) ticking merrily away.
(Our `uptime` tool for Windows [0] reported the actual time the machine was up correctly.)
Restoring all my work every couple of hours was becoming a pain, so I decided to re-enable hibernation support on Windows for the first time in 10 years... And surprisingly it works absolutely flawlessly.
Even on my 12yr old hardware, even if I'm running a few virtual machines. I honestly haven't seen any reason to reboot other than updates.
I'm in SA too, and I used to have 100s of days uptime (one even over a year and a half) ... until the regular blackouts.
Had to stop using a desktop, I've resigned myself to using a laptop, purely so that I don't have to boot the thing all the time and lose my context.
I'm from the first set of people and the only reason I stopped shutting down my macbook is because I'm now keeping its lid closed (connected to display) and there's no way to turn it on without opening a lid which is very inconvenient. I still reboot it every few days, just in case.
$ uptime
15:39:13 up 359 days, 2:02, 16 users, load average: 0.09, 0.08, 0.15
16 users is 16 tmux sessions, all me doing different tasks.One of the fascinating curiosities you're missing out on is Pressure Stall Information (https://docs.kernel.org/accounting/psi.html). Here's what the PSI gauges look like in htop when kernel support is available:
PSI some CPU: 0.37% 0.78% 1.50%
PSI some IO: 0.38% 0.33% 0.25%
PSI full IO: 0.38% 0.31% 0.23%
PSI some memory: 0.02% 0.04% 0.00%
PSI full memory: 0.02% 0.04% 0.00%If there was no boot failure, nor the need to reboot after some upgrade, I'd never, ever reboot my system.
Why? I only restart my (linux) laptop every 3-4 months when I update software.
I can't think of any downside that I've experienced from this practice. I do a lot of work with data loaded in a REPL, so it's certainly saved me time having everything restored to as I left it.
I would never suspend to RAM or disk, far too error-prone in my experience. (Plus serializing out 128GiB of RAM is not great.) I just leave my machine running "all the time." My most recently retired disks (WD Black 6TB) have 309 power cycles with ~57,382 power-on hours. Seems like that works out to rebooting a little less than once per week. That tracks: I usually do kernel updates on the weekend, just in case the system doesn't want to reboot unattended.
Hey, I'm that guy (although I put it to sleep instead)! It honestly works really well and is in stark contrast to how Linux and sleep mode interacted just ~10 years ago. It's amazing for keeping your workspace intact.
(FWIW, I also don't reboot or shutdown my desktop where it acts as a mainframe for my "dumb" laptop.)