1,389 karma · joined April 23, 2010
On the other hand, I have a three statically linked binaries for CloudFoundry in my home directory. One for Linux, one for MacOS and one for Windows. They are each between 24MiB and 27MiB each.
One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Kerberos realms also closely resemble DNS names and discovery can be tied into SRV records and well-known-names.
Kerberos tries really hard to do authentication and rely on other, existing systems for the other bits. If your resolver supports DNNSEC then it'll check your Kerberos-related DNS records as well.
On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Corporations and other entities typically use Active Directory on local domain that's not otherwise used on The Internet. SSH keys are trusted on a per-key basis, so I don't see a great need for it to be tied into the Web/SSL CA systems because trust is established in other ways and it's almost always with an entity that you already know or have a relationship with.
Of course, there's a case for delegation, etc within an organisation, but that's a different problem to delegation in global DNS.
I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
(Last time I used it) V5 was reasonably safe to use on the open Internet. It integrates well with MacOS, Linux, BSD and other Unix auth systems and also with SSH.
I never really understood why we don't see more of it in "Cloud" models, especially given how decoupled a Kerberos Principal is from the underlying Unix UID.
Rather than using SSH keys everywhere and thus having to manage .authorized_keys files all over an estate, the users can `kinit` in a terminal (even on a stock MacOS) and they're away. The credentials are managed centrally. It has service/user and delegation properties similar to oAuth and friends.
I've not looked at it with a modern and critical cryptographic eye but, for example, there is (configurable) support for not giving out the initial set of tickets (which is encrypted with the user's password) until the client has proven it knows the user's password.
Many browsers (especially on the MS platform, but definitely also Firefox on all platforms as well) can be configured to use the tickets for HTTP authentication (like BASIC or DIGEST, but using a different scheme) at configured domains. Lots of web servers and web apps are easily configurable to put the correct things in the correct environment variables or HTTP headers so integration with random web services is straightforward.
Once you've got SSH and Browsing covered with a single credential, you're well on your way to a really versatile SSO scheme.
It's called "PID Without a PhD" but it still assumes at least an undergrad level training.
I wish it had been around when I was studying EE-2-Control. That was not one of my favourite courses but is one of the bits of theory that I have reached for the most since and this guide has been a very useful reminder of much of it.
NXDOMAIN is a valid response that won't pass a signature verification.
REFUSED just means that DNS Server can't or won't provide a response at this time.
Cloudflare is optimising for SSDs.
They don't talk about latency: all their crypto benchmarks measure throughput. Near the end they hint at response time for their overall cache system but there's no detailed discussion of latency issues.
The takeaway for me is that I'm OK with what's currently in Linux for the HDDs I use for my backups but I'd probably lose out if I encrypted my main SSD with LUKS.
At the end of the article they say that they're not going to upstream the patches as they are because they've only tested them with this one workload.
I'd also be interested to see a benchmark comparing SW AES with FPU-saving + HW AES. Unfortunately their post does not include stats for how often their proxy falls into the HW or SW implementations. Whatever those numbers are, I'd expect FPU-saving + HW AES to be somewhere in the middle.
The argument doesn't hang together. He can't claim that changes to userland tools aren't possible whilst at the same time claiming it's because the existing interfaces never change.
I really appreciate you taking the time.
Obviously the web browsers are a big requirement.
...but I've had trouble with the defaults for almost everything I've tried: xterm, libreoffice, browsers. Under KDE the menus are too small by default. Under non-Gnome-or-KDE window managers or desktop environments almost everything is rendered too small.
The chances are that I can't just install an application with `apt-get` and have it do something sensible by default without a lot of fiddling and customisation.
Much of this criticism of X was prescient for things to come. Autotools, dependency problems, modularity issues, compatibility, "DLL-hell", etc. Many of these problems don't have solutions today that are orders of magnitude better than then.
On the other hand, one thing that's really holding X back, especially on handhelds, is 'Myth: X is "Device Independent"'.
If the difference between a 75dpi screen and a 100dpi workstation screen was too much, today's "retina" displays really struggle to run a usable X. You're heavily reliant on the toolkits (Qt, GTK, etc) to scale things for you and they mostly understand about font scaling but not about widget scaling.
Lots of distributions that might want to use it, for example Maemo Leste, Ubuntu Touch or Gemian, are having to do a lot of UI work and hand-pick applications for "porting" to the screens and input devices (touch) that they want to use them on.
This means that Linux-on-the-smartphone is not yet in any position to give Android or iOS a run for it's money because it really struggles to effectively leverage its existing app ecosystem.
Even ignoring security models, X struggles to provide even a compelling visual of a vision for handheld devices.
Don't even mention Wayland: that has other economic incentives that are not yet properly aligned for widespread success (including X's app ecosystem ones).
In at least one of his essays he argues that founding a company creates wealth and wealth creation does two things.
1) Makes society as a whole better off. i.e. "A rising tide lifts all boats", so the poorest in society benefit as well as the richest. The mean value of all individual's wealth increases.
2) Increases inequality because the distance between richest and poorest increases. The variance in individual's wealth across the population increases.
Of course, these are just arguments he puts forth. Others may disagree with them. ...but I think it's worth trying to understand the distinction he makes between "inequality", "wealth creation" and "improving society as a whole".
You are required to enter the US on your US passport if you have one.
If you wanted to go back (say to the funeral of a friend, or something equally important) then they could detain you until you paid what they thought was due.
They invented this model!
They were the first to realise that web-based startups didn't need a whole lot of capital and that the mentoring and guidance part was where the USP was for the investor in this sector.
This is especially true when the dialogue is between two people (or entities) of different social status or power, but it's also pretty rude to not oblige when you are close to the person.
The only time it is truly voluntary is when there is no relationship and nothing to lose by declining.
Priority in particular is quite subjective and also changes depending on what else is going on (other tickets perhaps?)
Having said that, the bug tracker we use provides the fields by default and we try to use them intuitively. We also try to discourage the "everything is P0" behaviour that happens when people use an arbitrary numerical scale. (What even is P0? I see it pop up when people discover that all their current tickets are P1.
Anyway, here's ours. They're kind of ordered but mostly try to be descriptive and sympathetic to the idea that the judgement is subjective:
Priorities
* "If time permits"
* "Next"
* "Do not defer"
* "Blocks dependants"
* "Release blocker"
* "Don't go home"
The default is "If time permits".
Note how all of them are pretty "important" sounding except the "lowest" which instead admits that sometimes things just can't be done because of other factors rather than because they're not important.
"Next" means "do this next" or "in the next phase of work / sprint / release" and things can climb up to this priority as we take decisions.
"Do not defer" means that it must be done in the milestone it's allocated to. It can't be deferred to another milestone. i.e. we've made decisions that mean it can't be deferred to the next phase. This is for things that we'll need for the next phase or will become blockers but aren't yet. It's not for things where we have generally decided that Now Is The Time. There must be a specific reason it can't be deferred. We use the milestone features to actually decide what's in or out of a scope of work.
"Blocks dependants" is pretty high up and as such needs to be explicit about what it's used for. If your bug blocks something else or has something that depends on a fix then the schedule is going to get messy if it's not done. It's hard for someone with authority to wedge something in here because they feel like it.
"Release blocker" is also pretty high up. This is where people get to jump up and down and explain why they think their bug is so important (and why it's doesn't fit into "do not defer"). This is for stuff that means we can't actually ship the release rather than things we'd just like to be in it. For example "we can't build the software until this is fixed". Hopefully reasonably rare stuff. You need to explain why this blocks a specific release rather than the release otherwise being enough better than the previous one to deliver value to users.
"Don't go home". Sometimes things really are that bad and need to be fixed. At least the person assigning this knows what they're asking, what the implications are and how bad it looks if everything always ends up in this bucket.
Severity works a bit differently. These things are hints from the reporter about the impact of this bug. They really are very subjective.
* Don't care
* Embarrassing
* Minor peril
* Major shitstorm
* QA blockers
* Showstopper
"Don't care" is the default. We want to capture everything we know about our software and encourage people to not feel too "whiny" about filing the notes. This is often for things that end up as "enhancements" or "tasks" rather than "defects".
"Embarrassing". This is something that a user would notice and be left with an impression that we have less attention to detail than the best in the industry.
"Minor peril". This is a bug that's going to cause friction or trouble and give the user an uneasy sense or stop them from building confidence in the software.
"Major shitstorm". I'm never profane in my software but someone suggested this and lots of people liked it and had a good idea of how it should be used. This is for stuff that causes problems when the feature is used. Stuff that leaves a persistent mess that needs to be cleaned up by hand or corrupts some state or something.
"QA blockers". Without fixing these bugs then we're unable to test our software properly. This means we might attract regressions and we probably shouldn't be releasing stuff to users. For example, if you can't save a record that contains the new features then you can't test the corresponding load functionality.
"Showstoppers". These are bugs that cause the whole software to break. Crash bugs, things that destroy user data, etc.
Most of our open bugs mostly sit at "don't care", "embarrassing", "if time permits", "next" and occasionally "do not defer". If stuff starts creeping up the ladder then we know we have a problem coming. If stuff starts to appear straight at the top of the ladder then we get those things fixed ASAPs: they don't hang around as "open" for very long!
A lot of the "higher" values are things that help us deal with interactions. Problems on their own are often tractable. When things start affecting other things and causing knock-on effects then trouble occurs. We try to head that off by knowing about it when it comes in and fixing those things quickly.
However, the lede is somewhat buried:
“There’s a bunch of noise about the U.K. government possibly trading away enough data protection to lose adequacy under GDPR, at which point having them in Google Ireland’s scope sounds super-messy,” Kissner said.
It's possible that, over time, the UK will adjust its laws and lose EU "adequacy". This currently seems unlikely so the game, from Google's point of view, is to work out whether to move out early and cause a sensation or to wait until it happens (if it happens) and then make a rush then.
It's complicated because things may change gradually, over a long period of time, and there may be some things that are advantageous earlier or later. Also, Google might not want to put itself in a position where it appears to be trying to influence British law: "if you change that particular thing, we'll move out". If they do it up-front under the guise of Brexit then they put themselves in the best possible position to use the data as they wish (within whatever law applies) and avoid such accusations later.
This is complex and involves a lot of game theory.
You didn't have to have all the capital. They'd rent you the machine on a long lease and you could say you'd bought a million dollar computer.
Sun tried to get into similar markets but it was always a tougher deal on minis and micros.
$100K has always been "cheap" for a "business computer" and today you can get more computer for that money than ever.
$100K of hardware (per year or so) is small-fry compared to almost every other R&D industry out there. Just compare with the cost of debuggers, oscilloscopes and EMC labs for electronic engineers.
You don't have to run it full time tho'...
In the very last paragraph of the article they then say "...on the back-end, most modern enterprise software (e.g. Salesforce, Jira, etc.) now have good APIs for exporting data. ETL + data lakes are on the rise...".
This is a mistake I see made a lot; not because of naivete tho': usually because the concerns cut across each other so much.
The economic and efficiency incentives around integration are very delicate. SAP is so complex that (assuming you can hire great engineers, which isn't necessarily a given outside the tech sector) you can probably build most of what you need with a small team that's much cheaper than SAP. However, you can't successfully (even with good access to great tech sector talent) grow that software as quickly or as broadly as what you'd get from SAP. You also carry a lot more risk. ...and that's risk outside of the core focus of your business. The article even includes one quote, "competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP." which recognises this as an operational rather than capital problem.
...but even if you can accomplish it, it's the integration that gives you the value. You're always going to have higher operational costs for your thing if you build it out of something like Salesforce and Jira sewn together with APIs. ETL is hard to do well for anything other than reporting (and even then it's not easy). Data lakes are the epitome of loosely integrated data structures. Most of the time they're a collection of files full of data in weakly-or-stringly typed formats such as CSV, JSON and XML. Getting at the domain models of the producing software is always a pain. For all these things, your talent pool for effective support is small and gets smaller as you add more products to the mix.
So the three options are:
1) Buy (+ professional services)
2) Build
3) Integrate (e.g. "Salesforce + Jira")
3 (Integrate) is the mistake because it's less than the sum of it's parts. You carry all the risk of "Build" and don't get the brand stability and integration of "Buy". Multiple vendors gives you more risk than a single one in this scenario because you're buying different things from different vendors. So now you have more chances for failure: failure or withdrawal of one of the vendors, API changes that you don't control, etc, etc.
As the SaaS markets become more mature I'd hope to see consortiums of vendors who had products that they would certify as working together. I don't think we're quite there yet tho'.
2 (Build) is the Big Bet because you're taking a capital expenditure approach to an operational problem. You're investing in intellectual property outside of your core business. ...and you own all the risk.
1 (Buy) is difficult because it is expensive and loads of things you want are still only sold on a professional services basis, rather than as a product. It's also a market designed for the large companies with between 6 and 9 figures to spend. It's also one of those infrastructure projects that is usually shaped as something that doesn't deliver any value until it has been rolled out everywhere. However, this is the option where you hold the least technical risk and most of the risk you do hold is related to abilities that are hopefully aligned with your existing skills of management and operational delivery.
Instagram is asserting that this software is such a tool.
"The complaint claims that the tool 'Instagram-API' allows unauthorized access to Instagram users' posts, which the company says are copyrighted works to which it grants protected access."
More info here: https://torrentfreak.com/instagram-uses-dmca-complaint-to-pr...
It seems to support a lot more than traditional MIDI, especially in terms of control and synchronisation.
Does anyone have any idea how well MIDI 2.0 and OSC will compete with or complement each other?
The guarantees they present in that article seem a lot stronger than the HN submission. They explain what they intend by "self limiting" and then it turns out that it doesn't work anyway (with a 4% survival rate of Female carriers in the wild).
In the HN submission (a later experiment) they don't seem to be anywhere near as careful. They just say it's "self limiting" but that the genes are passed onto offspring (of which, the males survive).
I'm not an expert in genetic biology and my differential calculus is rusty but, intuitively, I'd expect that if you had even a small percentage of matings that didn't produce Female offspring then the overall proportion of males would rise. It's not immediately clear what the equilibrium point of male carriers would be.
...so how does it "self limit" in the case where the limit is not merely "all (female) moths have died"? Do all males end up infected?
What is the range of these moths? Can they fly to other places and gradually spread out over a geography?
I have so many questions and, to a non-expert, it all sounds rather scary!
----- During the initialization sequence the bus master trans- mits (TX) the reset pulse by pulling the 1-Wire bus low for a minimum of 480µs. -----
There is no maximum time limit for the reset pulse.
----- The bus master then releases the bus and goes into receive mode (RX). When the bus is released, the 5kΩ pullup resistor pulls the 1-Wire bus high. When the DS18B20 detects this rising edge, it waits 15µs to 60µs and then transmits a presence pulse by pull- ing the 1-Wire bus low for 60µs to 240µs. -----
A tolerance of 15uS to 60uS on the device side and 60uS to 240uS on the driver side seems pretty wide to me.
Now, it's hard to actually get a good figure for these specifications because different datasheets give different values, which further suggests the tolerances are large.
Another datasheet that I have here says that the presence pulse should be sampled after 72uS. This leaves at least 12uS slack for rise times, long wires, etc.
To give an idea of whether 10uS is very long or not, remember that the cycle time on, for example, an 8MHz AVR as you might find in an Arduino, is 125nS. That gives you 80 instructions every 10uS (at the AVR8's advertised 1MIPS/MHz). This is plenty of time to implement the 1-Wire driver in software.
Maxim have documentation about the fact you can get device IDs but I've never actually worked out how to get some. I guess people didn't want to be reliant on Maxim as the numbers authority?
It's pretty popular for simple serial number / "Number In A Can" applications tho'.
Obviously that requires more hardware on the board tho'.