andyjpb

Being able to select desktops/workspaces per screen is half the solution.

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

...

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!

Hi,

This reply is a bit late because someone pointed me at it and suggested it was worth answering. ...so I hope that this is useful!

I have experience using Chicken Scheme in production both on knodium.com and registers.app

Both times it has gone well.

There's an HTTP implementation ( https://api.call-cc.org/5/doc/intarweb ), a webserver (https://api.call-cc.org/5/doc/spiffy that supports SSL) and an HTTP client ( https://api.call-cc.org/5/doc/http-client ). There's also an "app server" that tries to be like other app servers you might already know ( https://api.call-cc.org/5/doc/awful ).

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.

Knodium is now long gone but there's a video of what it looked like here: https://www.youtube.com/watch?v=gOPuWi-dbQg

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 built a bunch of things along the way and released as many of them as I could as open source: http://wiki.call-cc.org/users/andyjpb

We're currently doing https://registers.app with a similar stack so I'd be pleased to talk more if anyone has any questions.

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.

If you have hypervisor access you can simply ask the guest to read the memory for you.

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.

You're not strictly wrong...

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.

Yes!

http://wiki.call-cc.org/eggref/4/email-address

https://bitbucket.org/knodium/email-address/src/master/email...

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.

Facebook don't "sell ads". Well, literally, they do.

...but the product they're actually offering is "behaviour".

They sell access to the levers to influence behaviour.

The author seems to be soliciting artwork submissions for a "Pobox clock" as well so perhaps we could use this opportunity to help out!

https://humanclock.com/poboxclock.php

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.

As with all classification systems, one should beware the Celestial Emporium of Benevolent Knowledge: https://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevole... or be doomed to repeat it.

Reading between the lines, I assume that it's because Red Hat / IBM own that trademark and they've decided to stop using it for that project.

In principle, there's no reason why another-CentOS couldn't come about in the same way as CentOS came about originally.

...but now that CentOS has been professionally funded for so long, the bar is higher than it used to be.

I guess the free lunch is finally over.

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.

I guess the advice starts out helpful: violet might be a good substitute for blue in certain situations.

...But saying "we have all these other things that you've already told us you're aware of" is where things start to get passive aggressive.

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?