HN user
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!
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?
Yes.
If there's an illegal number X and I give you a number Y with the intention that you obtain X from it by some transform then Y is also illegal because I "tainted" it when I did the original transformation from X.
If I just need Y (or X) for some operation that's not related to the "illegality" then those numbers are not illegal.
The essay that droffel linked to explains this very well.
No matter how horrible X may be, it has a lot of value for end users. Almost all of this value is in the ecosystem around X.
You can't capture an ecosystem unless you provide that value, plus the activation energy needed to persuade people to change.
systemd (as an example of a large, recent, change to the "whole system") touched end-users far less than X so the pain was felt mainly by distributors and sysadmins.
Time and again, software that's "better" fails in the market because it doesn't provide the things that users need, want or use.
Backwards compatibility is usually key when trying to capture a large, long established user base. ...and that means backwards compatibility even (or especially!) with all the "bad" or "wrong" stuff. This is one of the things that makes software "products" much harder than software "engineering" (which in turn is "harder" than computer science).
Science is how it works. Engineering is getting it to work and productisation is getting people to adopt it.
Wayland has to solve problems that end-users actually care about rather than just being better in technical ways.
I think what actually killed Wave was an insufficient focus on making the UI really slick. It may have been too early for its time, needing some of the Internet technologies that were invented later.
I think this is what Jetrel means when they mention that the good engineers were/will leave. For GMail they pioneered the technology needed to implement the UX and UI they wanted.
Why couldn't they do it again? Because they're not the same kind of company with the same kind of mindshare?
If you look at where webmail was when GMail came out and compare it to where corporate chat is now, Google just don't seem to be (successfully) taking the same advantages. I know plenty of companies who use G-Suite plus Slack.
If I remember correctly, Groups.io was started (~2010s?) by the founder of Onelist (~mid 1990s) which merged with eGroups (~2000) and was subsequently purchased by Yahoo and became Yahoo Groups.
It just goes to show that Yahoo could have innovated to improve the product but was unable to. The original founder understood the needs and how things have changed (or not) over the past 25 years.
I've been using this recently and, because it doesn't ever modify the file system structures, you don't have to worry about unmounting the volume cleanly.
It can write to files, but it can't create or resize them. For that (and more), you want FatFs, the full featured version: http://elm-chan.org/fsw/ff/00index_e.html
elm-chan has also written an AVR bootloader that can update the flash from, for example, an SDCard. It uses this Petit FAT File System Module and requires a 4K bootloader section (so mostly of use on the ATMega1284).
On the other hand, manufacturing has the general attitude that "software is free" because the incremental cost in production to make a copy is zero.
Once, the production team swapped a component as part of a running change and it took a programmer nearly a month to write the new driver.
I think we still came out ahead in the end but there was some worry along the way as it wasn't clear how long it was going to take.
Cents is a lot of money in manufacturing.
When I made consumer electronics our production team would swap parts based on cost. 1c on a million units is $10,000. They only had to save a few cents a year each to easily pay for themselves.
The rest was margin for the business.
Saving cents on a $80 BOM (bill of materials) may not sound like much but it really does add up when you're doing volume manufacturing.
This is a much easier problem as the input is large but streamable and the database is small.
However, you would still need to use some of the tokenisation steps that he talks about such as finding word boundaries and stemming.
The performance of your problem would be bounded by the size of your unseen text.
Something like the The Knuth-Morris-Pratt string-search algorithm would be useful.
This is a great intro to full-text search.
These techniques were the basis of some of the early web search engines (pre Google).
More of this stuff is explored in Witten Moffat and Bell's book "Managing Gigabytes" which dates from the era of those early search engines and when "Gigabytes" was something unimaginably large that certainly wouldn't fit in RAM and perhaps not even on a single disk.
I'm not a JS programmer so the intended "simultaneous" waits only vaguely registered as possibly problematic.
However, after reading the article it is, at worst, a performance problem.
...and performance should come after the code is correct and I don't think the code is even semantically correct in the first place.
I'm assuming that "members" and "non-members" are distinct subsets of all People. i.e. it's not possible to be in the "members" and "non-members" sets at the same time. Additionally, everyone is in one or the other.
Because the set membership is queried with 2 independent queries (designed in a reasonable and common RESTful manner) there is a race condition where an object (that changes in the time between the two calls) might appear in neither or both of the sets.
These results are then blindly concatenated together.
If the API wants to retain its RESTful design, it must include metadata about the consistency between calls. For example some kind of token that can be compared to check that the replies to the two queries represent a consistent view of the data.
If the tokens, differ, the "transaction" can be retried.
Alternatively, the API can be designed, possibly making it less RESTful in the process, so that the transaction is implemented on the server.
There are many other ways to guarantee a correct and consistent result.
Either change has big enough implications that optimising for performance at this stage would be premature because of the amount of refactoring necessary to implement `getPeople` in a way that provides consistent and correct semantics.