You don't have to meet the requirements of "a mix of letters, numbers, and special characters."
e.g. a 15-character password without complexity could be all lowercase letters.
694 karma · joined August 19, 2016
e.g. a 15-character password without complexity could be all lowercase letters.
I think it's easy to have both. It's all about the tone of the responses.
For example, instead of "your assumptions are wrong, this would collapse because X" or "this is dumb because real Twitter does Y which yours doesn't handle," I think responses could be framed as:
"Wow, neat thought experiment! If I were to approach this same problem, I might make an allowance of more than 280 bytes of storage per tweet to allow for additional metadata that is probably needed to make everything work together; I wonder if that can be accommodated with an even beefier big computer?"
Or "What a great writeup of building a simplified Twitter! After the features you've accounted for, the next most important feature of Twitter for me personally is Y. What kinds of things would we have to do to stretch your idea to handle that? [or, I bet with the addition of X we could make that happen in this setup too!]"
I think many criticisms could be turned into constructive positive additions to the original article versus attacks against the idea of the article.
If there's any optional part of POSIX, it's not in there. You only get the 'MUST' parts of the base spec. No optional extensions, etc. When you're porting over C code to z/OS USS, you are often surprised when things you assumed were just part of every POSIX implementation aren't there. Fun times for all!
If it was AIX, it wasn't a mainframe. AIX runs on IBM's POWER systems, which are their "midrange" line. (There was, for a brief time, AIX for S/370 I believe... but that disappeared long ago.)
Mainframe would be a System z (the S/360->S/370->S/390->z/Arch lineage), typically running z/OS (or Linux for z!)
> Tiny discrepancies don't randomly appear during float operations
They don't "randomly" appear, because as you say IEEE 754 is well-defined, but discrepancies _do_ appear, and if you care about the concept of equality, they certainly matter.
Take a trivial example in C:
#include <stdio.h>
int main(void) {
volatile double a, b, c, d, e;
a = 5.0;
b = a/3.0;
c = b/3.0;
d = c/3.0;
e = d*27.0;
if (a==e)
printf("EQUAL\n");
else
printf("NOT EQUAL\n");
return 0;
}
Hence why when you're talking about comparing equality of IEEE 754 values, you can't just do a comparison of the bits in storage.
You're right that all (correctly implemented) systems will accumulate errors in the same way (assuming you've selected the same rounding mode, etc.), but I don't see how that negates the need to handle the fact that the representation in memory of e will not equal a even though they _should_ represent the same value. Given the sequence of operations performed, how much "slop" should you allow when comparing a to e? Certainly more than 0 which a bit-by-bit comparison implies.
I think this is run by a company that does offer commercial AS/400 instances, but they also provide free non-commercial accounts on this one box. Which is nice because it's not trivial to get your hands on your own system as a hobbyist.
> Have never used AS/400, but from all what I have heard it is horrible even compared to CMS.
I wouldn't say it's horrible compared to CMS. It's just _very_ different. I have played with quite a few operating systems...it's a bit of a hobby of mine... and OS/400 is the most different.
In terms of writing simple terminal-oriented forms applications to do basic CRUD operations against a relational database, OS/400 is actually pretty nice.
It's just such a WEIRD system.
The thing I find frustrating about it is that while it has a lot of interesting security controls, the defaults are wide open and I suspect there aren't a lot of people who could secure it to the point where you could give untrusted users "shell" access and not worry you've left some little nook or cranny open to them that you didn't mean to. [Presumably at least one of those people are involved with the pub400.com system!]
These days (and for quite a while), the boxes that run IBM i are the same POWER servers that can run AIX and Linux. Before the platforms consolidated, they were still POWER servers, it was just a different firmware between the "i Series" (ran OS/400) and "p Series" (ran AIX and Linux) POWER boxes.
I always think of 2FA as insurance against password theft/leaks. If users don't practice good password practices and use the same password for multiple accounts, for example, when ${next web site to be hacked} leaks all plaintext passwords, you can't just turn around and use that password to access ${another site where I used the same password but have 2FA enabled}. Or I'm logging in to a site from someone else's computer and they have a keylogger. [Obviously this virtual 2FA device wouldn't let me log in in that scenario--but in general, this is another case where the 2FA doesn't have to be rock solid, it just needs to exist if you captured my keystrokes.]
A direct attack on my workstation to steal my virtual 2FA device and my passwords isn't protected by this virtual 2FA device, but that's low in my list of worries overall for people's account security.
It would be difficult to make the software unavailable, that cat's out of the bag and it runs into problems with free speech, compelled speech, etc.
But the prevailing interpretation over the years of the Commerce Clause gives the Federal Government enormous constitutional power to do just about anything it wants when it comes to regulating anything that has any remote conceivable effect on interstate commerce.
So I don't see what would stop them from saying you can't buy or sell goods with cryptocurrencies. They can make it illegal for any federally regulated bank (i.e. all banks) to get anywhere close to cryptocurrencies, such as accepting deposits from customers who traded crypto for cash, or providing banking services to companies that accept or trade in crypto.
The Federal Government can withhold various federal monies from states that don't agree to implement similar restrictions domestically (that's how Congress can get around the "interstate commerce" part of the Commerce Clause--they can just bully states into complying with Congressional desires that the Constitution doesn't grant Congress the power to enact).
Enforcement, of course, is another question. But if high-energy-cryptocurrencies are effectively declared illegal in the U.S., a majority of current users will likely not want to try to get around the legislation and that may be enough to shrink the market small enough to have the desired effect.
The relevant parts of HIPAA are the duty to not disclose PHI to unauthorized recipients and breach notification requirements if you do incorrectly disclose PHI (the HIPAA breach notification rule).
The magic of encryption is that HIPAA provides safe harbor if the data stolen/lost/intercepted was encrypted to certain standards. So if you lose an encrypted hard drive full of PHI, or someone breaks into your servers and steals encrypted data but not the decryption capability, then it's not considered a breach under HIPAA and you do not need to notify anyone.
Tons of PHI isn't stored encrypted at rest. Physical theft of the hard drive from the practice's back-end EHR database server hasn't generally been high priority on the HIPAA breach potential risk assessment list. But nearly all data in transit, on employee laptops, etc. will be encrypted, because that's where you want the safety net of the safe harbor provision.
The process DMCA uses is: 1) person claiming their copyright is being infringed sends a DMCA takedown notice to the platform. 2) Platform takes down the content (doesn't "keep it up and redirect revenue" like YouTube does) and notified the person who posted the content. 3) The person who posted the content can submit a counterclaim, at which point platform provider reinstates the content.
Then the person claiming their copyright is being violated disagrees, they have to sue the person in federal court for copyright infringement at that point.
Also there are penalties for making false DMCA claims. There don't appear to be ANY penalties for repeated, egregious violations of YouTube's own claim system.
What YouTube is doing isn't DMCA enforcement AT ALL.
The deep field image says it's about 2.4 arcmin across[1], Stephan's Quintet image is about 7.4 arcmin across[2], etc.
[1] https://webbtelescope.org/contents/media/images/2022/035/01G... [2] https://webbtelescope.org/contents/media/images/2022/034/01G...
You need basic addition and subtraction to always be exact (e.g. $15.27 + $91.31 needs to come out as $106.58, not $106.5799999999999999999998), and for operations that may have remainders beyond your desired number of digit precision, you need deterministic rounding or other rules to handle it.
If you're ever writing any code that handles money, DO NOT use just naively use float and double types in your code!
Assembly language is still a textual, human-friendly language where you can give memory locations symbolic names, you use mnemonics for the different machine instructions, many assemblers have various forms of macro support, etc. That all gets "assembled" or "compiled" into the machine code.
You lose type safety when using it. I'm guessing with generics in 1.18 now, we'll see an updated generic version of sync.Map whenever a bunch of new collection types are added to the standard library that take advantage of generics.
There are protected classes/categories that can't be part of the employment decision, but outside of those, the employer is free to set whatever criteria they want for the position.
If I run a plumbing company, I could say "all of our plumbers must have a computer science degree," and I can't imagine there's any legal reason I couldn't do that. I'd certainly have a recruiting problem, but not a legal problem as far as I'm aware.
Screenshot of everything happily co-existing: https://i.imgur.com/ctvlzCX.gif
This will tell curl, among many other applications, to save the necessary keys.
$ go mod init foo && go get github.com/spf13/cobra && wc -l go.sum
758 go.sum
$ go mod init foo && go get github.com/muesli/coral && wc -l go.sum
10 go.sum
For me, the killer feature (aside from tiling vs overlapping) is that on my three monitors, I can switch virtual desktops independently on each monitor. After being able to do this, I don't understand why every window manager doesn't offer this. It's not uncommon with tiling WMs that have good multi-monitor support, but you really can't find it in traditional WMs. There's an unmaintained patch of openbox--openbox-multihead--that added the feature, and there's an "experimental" hybrid window manager written in Go (by the same author of the openbox patch), but no mainstream window managers appear to have the feature. Apparently it goes against a requirement/assumption in the EWMH spec and breaks existing pagers. But that's okay, because I don't use a pager.
Anyway, it really is critical to how I work now. I can keep a set of windows on my right monitor, and flip between virtual desktops on my center monitor without the right monitor changing at all. (And no, using the "sticky" feature of other WMs doesn't work for me because sometimes I do want to flip to a different virtual desktop on the right monitor and have that set of windows for whatever context I'm switching to). Along the same lines, the pertag patch is part of making dwm the perfect windows manager for me.
(If you're interested in the particular set of patches I use and my config, I maintain it at https://github.com/racingmars/dwm)