I generally got excellents on performance reviews for my brief, entry level stint at Big Corp.
I still felt demotivated by the whole process, because it was a forced ranking of the system that wasted the whole teams time to say what everyone had already known: some of us did more work, some of us did less, and some of us were on a faster upward trajectory than others.
It turns out that it doesn't actually motivate any of your employees to throw social hierarchies in their face -- it only causes tension and undue focus on micro-social hierarchies (those heiarchies within a social class, eg, the hierarchy of entry level tech workers).
> I'm not sure if you're actually this dense or just trolling. What good can involving the police, after the fact, in a situation where nobody was harmed do?
People who do one reckless thing such as this demo are likely to do others. Calling the police about this incident means that they'll have a record of the people doing this, and if it becomes a pattern, handle it considerably harsher than an isolated incident.
Yes, we need a war on warez to go with our wars on terror and drugs, which have been rousing successive, having driven both of those social ills to extinction.
The war is on and we are losing. Yesterday a 56 year old bricky from Watford called my in panic. His old XP laptop was literally taken as hostage asking to call some paid phone number to unlock computer back again.
My point, since you missed it, is the instrumenting a "war on warez" in the style of "war on drugs" or "war on terror" is a joke, and should be disregarded as just the talking point of someone with a different idea trying to sell you something.
I don't believe maintaining a high availability system with proper checking is less than 3 hours a day of work, or ~10% of someone's time on duty if we're talking around the clock.
So we're talking about $75,000-90,000 a year in salary to maintaining the cluster if you want 24x365 coverage (which Amazon provides), as you'll need 2 people per shift, 3 shifts per day at a minimum to have people in house, even if they're only spending 10% of their time actually working on that particular issue. In reality, these are unrealistically small numbers. Each employee will have a cost to the corporation of $125,000-150,000 a year. Employees of that caliber spending 10% of their time on supervising a cluster for a year is $75,000-90,000. I'm amortizing the amount of work over your 3 datacenters by imagining you already have the staff and only counting out the number of hours needed for just this work.
So the reality is that you left off something like $225,000-270,000 in actual cost of running your own cluster from your analysis, because while it's not "much different", it is a few hours a week from at least 6 employees if you're really talking about running managed, highly reliable storage.
I feel like these comparisons oversell the level of support that actually comes with Amazon. Yes AWS as a whole very rarely goes down, but instances have problems all the time, and who do you call?
When you have your own servers and staff, even if they are just on-call with a pager, you know they are going to work for you on your problem until it is fixed.
In comparison, the sentiment about AWS is this: better build redundancy into the application because at the server layer, you get whatever you get.
This is simply a perspective on systems engineering.
My argument would be that part of the system is always down, the question is which part and how long, and how that impacts the system performance on the whole.
AWS services work well if you build a stateless system which is in some senses "embarrassingly parallelizable", because you can talk about the capacity of such a system, and the impact of non-functioning components is easy to predict. This is how most standard engineering is done, across disciplines.
Traditionally, it has not been the case in computer systems, but most modern techniques advocate using such systems, because they're MUCH more reliable.
You just sound like you need a safety blanket for emotional reasons, not that you're making sound engineering points about how to most cheaply engineer a high availability system.
I mean, do you really believe AWS engineers aren't working hard to keep their system fully functional?
The first post was a back of the envelope estimation, excluding externalities on both sides, to show why someone would want to keep all that "old, obsolete hardware". For Amazon, I didn't put in the costs of pushing data to amazon in terms of API calls used, bandwidth, etc. Additionally, I posted the cost estimate using their slowest storage system with the least amount of flexibility. The cloud doesn't always save you time and money.
I'm just saying that you omitted a major component, as no one would argue that the trade-off in engineering time isn't one of the main cost-benefit components of considering AWS (as we can see here, where it weighed in at a substantial fraction of your estimate).
It's like forgetting to count the price of hardware, and only talking about the relevant cost of electricity.
To be honest, I think OpenBSD is ahead on some fronts (research on security mechanisms, for instance), but the reason that I tend to use FreeBSD is that it actually works with software packages.
So the computers are based on FreeBSD (which manages the hypervisor -- and soon container daemon!), and appliances only are based on OpenBSD.
Well I don't know about that. I can't open Settings in Chromium at all anymore, the whole browser crashes. It also constantly uses 100% CPU for something so with Chromium open my load is always >1.
In VirtualBox none of the file open dialogs work.
If I switch to a console from X the whole screen glitches and gets stuck, I have to SSH in to restart/stop X.
Suspend doesn't work for me.
So yeah, it doesn't work on the desktop as well as Linux does. Haven't had any problems with it as a server though.
Oh and about the X thing, do you have a Haswell processor? And are you using the VGA driver for X? I had that, bought a $20 ATI card, works fine now, 3D acceleration in KWM and everything.
I use OpenBSD and haven't found software to be an issue. Certainly mainstream stuff such as Chromium, Firefox, LibreOffice, VLC, Evince, Gimp, Inkscape... all works.
The only piece of software I really miss on OpenBSD is the Android SDK, other than that it has everything I use and it works great. So once again I want to tell everyone reading this, if you haven't tried it and if your hardware is supported I invite you to give OpenBSD a spin.
I've been looking at OpenBSD but the partitioning setup (fdisk) is off-putting. Why are we counting heads/tracks/cylinders in 2015? Also, the labeling thing is weird but I could live with that.
Can you provide further details or examples of how these two projects did or do improve FreeBSD's Security? I know for example about ASLR in FBSD 11 coming from Shawn Webb et. al. from the HardenedBSD project..
Canaries and other techniques that leverage volatiles do not prevent an overflow; they just try to cope with the consequences of an overflow which has happened. (This is why they're generally lumped together as "mitigation".) The canary tries to detect the case of an overflow which overwrites the return address in a stack frame. Data Execution Prevention (DEP) takes this idea a step further, it assumes that the return address has been overwritten and followed, and it restricts the areas where execution could jump. ASLR is yet another step further: it "shuffles" the areas where execution is allowed.
More specifically, stack canaries work by modifying every function's prologue and epilogue regions to place and check a value on the stack respectively. As such, if a stack buffer is overwritten during a memory copy operation, the error is noticed before execution returns from the copy function. When this happens, an exception is raised, which is passed back up the exception handler hierarchy until it finally hits the OS's default exception handler. If you can overwrite an existing exception handler structure in the stack, you can make it point to your own code. This is a Structured Exception Handling (SEH) exploit, and it allows you to completely bypass the canary check.
DEP and NX (what OpenBSD calls W^X) mark important structures in memory as non-executable, and force hardware-level exceptions if you try to execute those memory regions. This makes normal stack buffer overflows where you set eip to esp+offset and immediately run your shellcode impossible, because the stack is non-executable. Bypassing DEP and NX requires a trick called Return-Oriented Programming (ROP).
ROP essentially involves finding existing snippets of code from the program (called gadgets) and jumping to them, such that you produce a desired outcome. Since the code is part of legitimate executable memory, DEP and NX don't matter. These gadgets are chained together via the stack, which contains the exploit payload. Each entry in the stack corresponds to the address of the next ROP gadget. Each gadget is in the form of instr1; instr2; instr3; ... instrN; ret, so that the ret will jump to the next address on the stack after executing the instructions, thus chaining the gadgets together. Often additional values have to be placed on the stack in order to successfully complete a chain, due to instructions that would otherwise get in the way.
The trick is to chain these ROPs together in order to call a memory protection function such as VirtualProtect, which is then used to make the stack executable, so your shellcode can run, via an jmp esp or equivalent gadget. Tools like mona (https://github.com/corelan/mona) can be used to generate ROP gadget chains, or to find ROP gadgets.
There are a few ways to bypass ASLR:
Direct RET overwrite - Often processes with ASLR will still load non-ASLR modules, allowing you to just run your shellcode via a jmp.
Partial EIP overwrite - Only overwrite part of EIP, or use a reliable information disclosure in the stack to find what the real EIP should be, then use it to calculate your target. We still need a non-ASLR module for this though.
NOP spray/sled - Create a big block of NOPs to increase chance of jump landing on legit memory. Difficult, but possible even when all modules are ASLR-enabled. This won't work if DEP is switched on.
Bruteforce - If you can try an exploit with a vulnerability that doesn't make the program crash, you can bruteforce 256 different target addresses until it works.
Again, the important theme here is that canaries, DEP and ASLR do not defeat overflows themselves, but target the generic overflow exploit methods which have traditionally been employed. The arms race between attackers and defenders in this space is becoming too specialized and increasingly, misses the point.
As feld indirectly points out, Capsicum is a much (much) better technology, because it traps the exploit (in a sandbox).
Capsicum extends file descriptors to include the notion of what you are allowed to do with the file. They already have some limited support for this. If, for example, you specify O_RDONLY to the open() system call, then you will get an error if you try writing to the resulting file descriptor. This is largely advisory: There is nothing stopping you from using fstat() to get the original path, and then opening it in a new mode.
This is where Capsicum enters the picture. After a call to cap_enter(), the program is in capability mode and is not allowed to create any new file descriptors via most of the standard mechanisms.
In particular, system calls like open() and socket() will simply fail. This has the advantage that it's a very simple test to perform and therefore quite easy to get right: Just check one flag and give up if it's cleared.
Capability file descriptors behave just like normal ones. You can pass them to any system call that expects a file descriptor, but you may get an error if you don't have the correct rights. These include read and write permissions—and also a variety of other things.
But Capsicum, Linux's seccomp-bpf (which Theo describes as 'insane') and OS X's seatbelt are all similar. Gaol (https://github.com/pcwalton/gaol) uses either seccomp-bpf or seatbelt as a backend.
Windows 8 has an equivalent of this, using a "mitigation policy" called ProcessSystemCallDisablePolicy, which is set using SetProcessMitigationPolicy(). Chrome uses this for sandboxing on Windows (https://src.chromium.org/chrome/branches/1312/src/sandbox/wi...) and uses seccomp-bpf on linux.
I believe capsicum is/will be used for sandboxing sshd, ping and tcpdump. Furthermore i know about Security Appliances making use of it, but that's about it, to be honest.
As noted below, Theo seems to be cautiously boarding the capabilities train with tame. That said, there appear to be some rather large issues with the implementation as it stands.
I just want to comment that I only clicked on the article after reading your comment about the original title, and I feel that the edited title less accurately reflects the material.
You added your opinion to the title, rather than leaving it alone.
Ed:
In fact, your title less accurately reflects the material of the paper, which specifically deals with:
> Finally, the United States would seem to be a rather dumb group entity of the relevant sort. If we set aside our morphological prejudices against spatially distributed group entities, we can see that the United States has all the types of properties that materialists tend to regard as characteristic of conscious beings.
Your title completely omits the key focus of the paper, and its examination, which the original title included.
You did this because you disagreed with the paper, and used the pretense of the nebulous notion of "clickbait" to edit in your disagreement.
The original title was more accurate as to the article contents.
I'm not sure what problem you think you're solving here: the existence of a queue suggests that they're slightly over capacity in cars, and thus something like Uber would still have to rotate the fares between the drivers.
Of course, there are perfectly sensible reasons that you need to have extra capacity available at an airport as a metro area, and thus we have the question of how best to provide surge capacity to the airport.
All the answers I can think of, including an "on demand app", involve waiting in some kind of queue managed by someone.
... then they could take fares around the airport and get matched for an actual ride at the airport without having to wait in line idly. The difference here is that they can make better use of their time while still possibly getting an airport fare, if that's what they desire for some reason.
That's what airport cabbies near where i live in India now do. The queue is really long (such that they may only get 1 or 2 rides the whole day), but now they take Uber/Olacab rides while waiting for their slot.
..then when they make their drop off, they'll have another fare request waiting for them and their downtime will be absolutely minimal.
If increased demand exists at the airport, pricing increases until capacity is met. This is a much more natural governor than simply creating a queue at projected in demand areas.
But his analysis applies even to highly technical users, for whom the problem is clearly not understanding.
The reality is I had an argument about why we should be writing down passwords at work, because the projected security benefit of preventing a full breach is still less than the expected benefit of not losing our data all the time.
Could we have set up a better, more technical PKI than notes in the safe? Probably. But I'm not sure it would get us ahead on the cost/benefit curve.
Real security is about separating your porn watching from your banking; not about doing your porn watching to the security standards of your banking.
tl;dr: No, dancing pigs are always more amusing. No one wants to live in a perfectly safe box.
I think that we are two sides of the same apple. I completely agree with you. I think that your argument is sound in terms of technology implementation.
My argument talks about motivation, not implementation.
> It's quite similar to other browser integrations.
"Online advertisements with active content aren't shady, almost all networks use them!"
Except for course, what you said it's identical are a notoriously shady group of activities, which has led to much abuse my market leaders at various times (Google, Microsoft), and we see no difference here. For that matter, neither do you.
I get that Firefox benefits from shipping the integration, but you haven't provided any good technical reasons for it not being fundamentally a shift in the way you do business and kind of exploitative.
Holding up a bunch of famous exploitations as "me too!"ing is tonedeafly missing the complaint.
Historically, the binary blobs provided as "browser integrations" are both major attack vectors and used by market leaders to exfiltrate inappropriate data under the aegis of "they didn't opt-out of our totally optional service!".
So yes, the market is fundamentally shady for "browser integrations".
There are no binary blobs involved here. The API endpoint is closed source, but the Firefox-side code is not. This is true for Pocket, Hello, and Search.
Ok, I think I understand your objection now. I can sympathize with your position - browsers would be purer without such integrations. It would be a better world.
I do think, however, that to compete with other browsers, such integration is necessary. If Firefox doesn't integrate with search, users will not find it useful, because they are so used to using google.com and so forth.
So I agree browsers would be better with no such integrations. It's a necessary, sometimes painful compromise.
> If Firefox doesn't integrate with search, users will not find it useful, because they are so used to using google.com and so forth.
This is a particularly weak case, because what's really needed for this feature at the browser level is an API for search providers, backed by several plugins which take advantage of the feature and offer various providers.
However, that's not what Firefox did here, as far as anyone can tell. Why not? No technical reason has been provided, and the replies have been so completely off topic as to cause a long debate thread over that very reasonable concern.
Firefox tightly coupled a technology to their platform rather than providing a service API and plugins, and we have no understanding of why a group committed to openness would make such a fundamentally close source move.
Historically speaking, the reasons groups do that is malice.
I still felt demotivated by the whole process, because it was a forced ranking of the system that wasted the whole teams time to say what everyone had already known: some of us did more work, some of us did less, and some of us were on a faster upward trajectory than others.
It turns out that it doesn't actually motivate any of your employees to throw social hierarchies in their face -- it only causes tension and undue focus on micro-social hierarchies (those heiarchies within a social class, eg, the hierarchy of entry level tech workers).