countingteeth
The property is taxed; the landlord pays the tax directly, the tenants absorb this cost in their rent.
Yes, a standard engineer's employment agreement prohibits engineers from performing patent searches.
Isn't this all a good argument that patents are hindering their intended purpose, e.g., PUBLIC DISCLOSURE OF INVENTIONS to advance the state of the art? If claims are written virtually incomprehensibly and are so useless as to not even be allowed as references to actual practitioners, I would argue they are not serving their purpose of public disclosure to advance the state of the art.
Also as far as I know pkg_add still doesn't know about restarting services, so vulnerable processes will be left running.
I thought credential caching was left out because it was another unnecessary bloated feature creep and doas is supposed to be minimal and more secure. Apparently people couldn't live without it, and it's added in three releases later.
Oh yes, another hand-rolled "coming item," in the world's most secure operating system. Someday, someday OpenBSD will support critical security updates that don't involve recompiling by hand. After all, we finally got "signify" for the base system. That wasn't important at all.
> or you can use mtier.
Right. That's called "on your own." I was going to preemptively predict someone would mention that, but the fact that paid consultants provide a critical feature for security updates as a service that every single serious Linux distro built-in for free is not a point in OpenBSD's favor.
> What the heck? I just use cvs. Its really easy http://www.openbsd.org/stable.html
Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.
And are you not forgetting that many of the critical security patches do in fact involve a series of additional steps that must be performed separately, manually? If you don't actually READ each patch, you can miss a necessary step.
And of course little things like restarting patched services automatically or knowing when a reboot is required, well, that's an exercise to the reader.
> The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.
I'm not using FreeBSD as a point of comparison here. I love OpenBSD. I also am not going to wave off how crippled it is operationally out of the box and basically unusable for production in many nontrivial real-world settings.
There's also the little issue of getting your head bitten off and shit on for no good reason even when you're only being helpful in the meekest and most good-faith possible manner, but that's only a little worse than par for the open source world.
1. The lack of an AppArmor-type MAC implementation is somewhat outdated since Theo rolled his own with "pledge". I'm not a huge fan of how a cabal of Theo plus one or two guys basically hacks out something of new cloth on a whim to solve a problem that's been done many times before, on the arrogant supposition they're doing it better than anyone else has ever done, and then promptly stuck it into production. This has happened many times before. Certainly some results have been good, but case in point, "doas". You upgrade one point release and suddenly sudo is not there any more, you have a new tool lacking basic features with completely different semantics. Yes, you can install sudo as a package if you want. Yes, maybe doas is smaller and easier to audit. But was sudo really a problem? Sure the fanboys will love it, but most normal UNIX people are probably not going to appreciate something like sudo just going away. It lacks little "features" like credential caching, which I am sure the fanboys will tell you is bad to begin with, but which most of the rest of us will find a pain in the ass. This sort of thing happens with OpenBSD semiregularly.
Of course, many of these homegrown solutions are produced after years of Theo & cabal insisting that there was no need for it and it was wrongheaded. There's "pledge," but then there's little things like full-disk encryption, which is basically a requirement for use on mobile, but which OpenBSD never had any use for, until it did, and came out with its own homegrown thing (which still doesn't work that great, especially when upgrading).
*And since so many others have brought up pledge, it's not really a solution on the same scale since you have to build the pledges into the application, there's not an easy system for imposing pledges on an application externally. This makes maintenance and adoption much harder, basically nonexistent for most of the package tree.
2. The big reason OpenBSD is insecure, is its lack of any meaningful update mechanism to their supposedly rock-solid secure base system. Literally the official way to do security updates is to monitor OpenBSD's website, download and apply patches by hand to a source install, rebuild, and run a series of listed commands by hand. If you want to automate this further, you are on your own. It's been this way forever. It's craziness, and it a big reason that OpenBSD is basically not an option for production in many settings.
Upgrading to new releases is a similar deal. The homegrown sysmerge hack has made this slightly less awful, but manual hackery is still required, unreliable, can wipe out customization, and doing a clean reinstall is still urged as the best path in many cases.
1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).
2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.
Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.
I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."
How about use a firewall that's not shit to begin with.
No it doesn't. Defense in depth is a thing.
RAID is huge defense for keeping "inevitable disk failure" from turning into "massive data loss."
Do you, personally, test backup and restore of ALL of your data that you care about at acceptable loss intervals? Are you sure?
And if your acceptable loss interval is "zero," then redundant synchronous storage across devices in one form or another is all there is.
Backup is a total real-world solution to data loss like antivirus is a total real-world solution to malware and infosec.
Then again, everyone is different.
Really? I've found blanket IP ownership to be more common than noncompetes, at least in US outside CA. My experience, is that noncompetes are more likely to be limited to key personnel, whereas the company IP is sacred and must not be tainted, and the employee is not to be trusted to come up with their own material on their own time, at least not without sign-off.
Blanket IP is really back-door antimoonlighting anyway. You can't very well moonlight as a software developer if your employer is encumbering your IP.
I'm sure the California startup world is different from my experience.
> DON’T use a real problem because of tribe knowledge needed to fix.
I do not see how this is different from a whiteboard problem, literally speaking. It's a "problem", not a "product", and presumably the solution is throw-away, or at least not used for commercial purposes.
If the author was talking about tasking potential hires with a small, real consulting task, then that would be an issue, whether it was paid or unpaid (and by industry norms, using applicants to do unpaid work is extremely unprofessional, though not unheard of).
1080p? Your point is invalid.
> and I had file sharing long before then
Oh, and how much storage did the typical user have ready access to?
A 2011 study found only 0.1% of student debtors in bankruptcy even apply for discharge of student loans. Yet of that self-selecting group, 40% were successful. The question is why more don't apply for discharge, and how successful they might be.
Regardless, this does show that "student loans are not dischargable in bankruptcy" is generally true, given a discharge rate of only 0.04%.
Source: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1894445
Iuliano, Jason. "An Empirical Assessment of Student Loan Discharges and the Undue Hardship Standard." Princeton University, Woodrow Wilson School of Public and International Affairs, Department of Politics. July 24, 2011. 86 American Bankruptcy Law Journal 495 (2012)
You can't very well tolerate an "atypical" GC pause when you're firing a laser or radiation pulse, doing engine control, or even updating a display in a flight instrument setting.