I've longed for a window manager that can assign different virtual desktops to different screens. Of course, there are compositing, scaling and resolution issues to overcome, but it'd be really neat to have a palette of virtual desktops that could be called up on whichever monitor was most convenient.
...and it'd make screen mirroring during presentations a breeze!
We had to write a lot of our own stuff but it fits fairly neatly into the scheme-way of doing things: you can get a remarkable amount done with just a few simple lines of code.
I'd probably want to write about as much in any other language as a lot of what we built were domain level abstractions.
We had a very talented web designer and we also built a "Widgets and forms" toolkit. I gave a talk at FrOSCon quite early in the development and it was saved for posterity: https://media.ccc.de/v/c116_lisp_-_2013-08-25_11:15_-_buildi... The first few minutes of audio are broken but it sorts itself out.
I can't find any docs other than what's on the page but my reading suggests that the idea is that you can get/set values "in-band" using a regular lookup query to a resolver rather than the nsupdate style that you'd normally use to remotely configure zones.
There is still Hesiod support in GlibC / NSS, etc on most modern systems.
When put together with Kerberos it's a nice way to provision auth on lots of machines automatically.
It's nice to have a dedicated and restricted resolver config so that the zone visibility can be restricted but that makes deployment a little more complex.
Encryption only helps if you can guarantee that your attacker can't get access to the layer below where the runtime decrypts things.
A cloud hack like the parent poster talks about assumes that you get access to the hypervisor layer and can look at the RAM of the guest machines.
This is not inconceivable. Rather, it seems quite reasonable given the complexity of hypervisors and the prevalence of CPU architecture bugs that makes these attacks easier.
Mutually Assured Destruction relies on the victim knowing that they've been destroyed.
Lots of these so-called "Cyber weapons" are operated by actors who are very effective at leaving no trace.
It's been in the background before but in the reports about this SolarWinds issue the "leaves no trace" angle is starting to be emphasised much more.
Not knowing if or what has been compromised means that the attacker can choose when or how to use the information they obtained and the victim will be surprised, even a long time down the line.
I think this outlook is very much part of the reason that Britons are worried about Facebook's move to Californian terms.
In the UK we do have very well established "Consumer Law" which is there explicitly to protect the consumer and recognises that they are often not otherwise in a powerful position.
The most relevant stuff for Facebook is the data protection stuff, but another example, relevant to other online transactions, is the Distance Selling Regulations ( https://www.gov.uk/online-and-distance-selling-for-businesse... ). This gives the customer the right to cancel, without a reason, for up to 14 days after the goods are delivered. If the business doesn't explicitly tell you this then your right to cancel is extended to 12 months.
But what I'm trying to say is that what's in your database should be well defined. You shouldn't just put any old stuff in there. You should have a standard for exactly how everything is escaped (or not) so that your consumers have a spec to work to.
You'd do the same with, say, character encodings. One option is to convert everything to a single character set on the way in, such as UTF-8. Another option is to annotate everything with the character set it uses. You must chose one.
Relying on adhoc code spread across the codebase for the security properties of untrusted data leads to whack-a-mole security situations.
Being able to trust the data in your database is essential.
Note, that absolutely doesn't mean things like "Robert'); DROP TABLE Students;--" shouldn't appear in database fields.
It just means that if you define the type of a field to be "eMail address" then consumers of it really should be able to trust that it really is a legitimate and valid eMail address. What does "valid" mean in this context? Well, that's up to your spec. Perhaps just "legally structured". Perhaps "something that eMail can actually be delivered to". Perhaps "something that is known and assured to actually be associated with this particular user".
...but you must be explicit otherwise consumers have nothing to work from and you're building castles on the sand.
This will allow your program to be used as a vector to attack the things your program depends on.
It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice.
Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.
It's a fair few lines of code but most of it comes directly from the RFC. It's also longer than it could be because it covers the entire RFC822 syntax, including groups, lists, routes, comments and To: header styles.
I usually put a few paths in between "find" and "-type", use the other predicates of "find" and often rewrite if from a just executed `find ... | grep`.
One particular modification is to extend the pipeline between the "find" and the "xargs" to filter the file list, especially `grep -v .git` ;-)
`find |grep -i ...` and `find -type f |xargs grep -i ...` have become old favourites.
This seems like an interesting system, provided you don't have more categories than you can easily remember.
If you use it in a team setting, there must not be more categories than the team as a whole can remember which is, perhaps counter-intuitively, fewer than you can probably remember on your own.
For ~15 years (since the launch of GMail) Google has differentiated itself on storage. Both in terms of products offerings and in terms of company image.
To me it signifies a change in the market. They don't feel like they currently need to compete with Apple or Microsoft on any of these fronts right now. The market is pretty stable and there are more battlefields ahead. So time to apply some levers at the points where everyone else is charging (iCloud) and get ready for the next big consumer adoption battle.
It makes sense right now but changes the playing field enough that some (old) disruption opportunities might start to open themselves up (again). I guess Google doesn't feel like those are a threat any more or right now tho'.
It'll be interesting to see what happens next. Bandwidth between handsets/eyeballs and datacenters is possibly one of the next most important costs and Google has a good story there. Lots of peering, a good network, and control of the software on both ends, so they are well positioned to make the most cost-effective use of that bandwidth.
The "corporate" answers in the support thread don't give any information, and the barrage of links to unhelpful and unrelated information make it seem like they're scripted and not really interested in their customers specific problem at all.
If AWS were to say what the problem was then people might be a bit happier to wait?
The other half is allowing the selection to come from a pool of desktops/workspaces common to all screens. i.e. the opposite of what i3 and Sway do.
So given desktops/workspaces a, b and c and screens 1 and 2, the following combinations are possible:
1: a; 2: b
1: a; 2: a
1: c; 2: a
...