Interesting objection. To me simplify taxes == simplify filing taxes. "I'm doing my taxes" does not mean I'm doing my tax code, but I am preparing and filing my taxes.
As a lawyer and tax accountant, do you see a flaw in the professor's approach? Any domain expert insight here?
Depends on what you mean by "preparing." If the tax code is simpler, that means that there are less lines to fill out and fewer pieces of supporting documentation to find and attach. When people talk about making filing simpler, they mean that the lines are pre-filled, and the supporting documentation is either easier to obtain or somehow not necessary.
I haven't watched the videos yet but I have been keeping my eye on TLA+ ever since seeing the whitepaper from Amazon and how they use TLA+ to spec out their distributed systems. As someone that works on distributed systems that could use some formality I think TLA+ could help, however, I have a hard time really understanding it.
Do you know of any straight forward non-trivial examples? Something a little more complex than "hello world" and something that isn't abstract?
There's a few I can think of! First, the TLA+ GitHub repo has a bunch of examples[0]. The best one to start with is the Die Hard puzzle[1], where the heroes must obtain four gallons of water given only three and five gallon jugs. In the spec[2] we set up the system and specify all possible actions; then we model-check the system to see whether it can spit out an execution trace of actions to reach a state where we have four gallons of water in a jug.
The Wikipedia article also has some good example specs[3].
For your own first specification, I personally cut my teeth on a river-crossing puzzle with a farmer, wolf, and sheep.
I wrote an essay[0] about a non-trivial example I did at my company. We had to work with several finicky APIs and the TLA+ spec caught several critical bugs with it. Plus, it's purely a business logic system, so it's pretty concrete.
If you're interested in learning more, I also wrote a beginner's guide[1] to the language, which contains concrete examples and exercises.
I have created the SAM Pattern [1] (State/Action/Model) based on my interpretation of TLA+. The goal is to make the semantics available to developers. Why not writing code as close as possible to the way it would be specified?
SAM can also be used for stateful API/Microservice orchestrations [2]
If you want a slightly more formal introduction to SAM and its relationship to TLA+ (again, based on my own interpretation) I gave this lecture last month [3].
Actually, TLA+ (again the way I understand it), after nearly 20 years of MDSE, convinced me that I would very rarely need to generate code. It's a much better value proposition to write correctly factored code.
TLA+ is one of the most amazing element of Computer Science. Everyone who writes code should have at least a basic understanding of it.
As someone who worked with distributed systems for many years before using TLA+ to find bugs and validate work: It's possible to understand it.
I think it would help to have a good mentor, as I did, or a lecture series from the language inventor. I ran through the trial version of these videos when Lamport was developing them and it's quite approachable even for someone who's more of a liberal arts kind of person.
I work on distributed systems and have started pushing for us to use TLA+/PlusCal to model them. I have a simple PlusCal model of a system with two threads which juggles network and disk I/O which I can e-mail you if you like. It's not at all a complex system, but I think it captures the basics of modeling concurrency and I/O well.
Or, were they paid one to begin with? I've hired people locally whose last gig was working remote for companies not based in SFBA and not making SFBA level wages.
The fear of job hopping is overrated in tech. Especially if you are leaving Uber, it'd actually make you look more attractive for actually having a backbone and a conscience.
In a period of about 3 years I went through 4 jobs. I never once was asked or told that my job hopping was a concern in any interviews (probably 50 all together) or offers.
Interestingly the only time I got push back on my "job hopping" Was when I left my first job that I was at for 3 years. I was being interviewed by my potential manager and one of his reports. As the interview was wrapping up the report piped up "How do we know you aren't just going to leave us in 3 years?"
The manager took control and smoothed that question over and I didn't have to answer it but it was an obvious power play and I'm glad someone else was in the room.
This may be true, but it's hard to get a sense of why you are or are not getting hired / getting interviews from the job-seeker's perspective, since you are not really privy to the decision-making process and can't really trust that the reasons given for them not hiring you are the real reasons (generally they don't owe you the truth and strategically it's often better not to say anything or to give some mundane reasons).
I've been involved in a small number of interview processes from the hiring perspective, and I've definitely seen some concern regarding job-hopping where it could easily make the difference on a marginal candidate. That said, this is only at one team in one company - and I was not involved in the initial resume screens (where people with a lot of job-hopping may have been eliminated entirely before I ever saw them). Probably would be best to get a broader perspective from people who have a lot more experience with hiring.
Indeed. I added my anecdote as a data point for arguments for being ready with a good explanation as to why you've left your previous employers.
Either they care and they don't call you, or they don't care and they don't ask.
In my experience the number of employers that don't care and don't ask are sufficiently large enough to not be concerned about the former employer type, especially for someone looking to get out of an uncomfortable employment situation.
This is great research but I think an important point is missed. It may come across that these images are vulnerable because of some intrinsic property of using Docker however this is not the case. What is also important to point out is by adopting Docker this analysis actually becomes easier to do across an organization and similarly mitigation becomes easier as well.
I think another aspect that is missed is that just because you use a vulnerable image doesn't necessarily mean you are at risk of being compromised no matter what other security layers you employ. This gets to the practical scenarios of security operations.
Absolutely agree. I did see some bad practices in the Docker community that I expect to see elsewhere as well. Specifically: reliance on deprecated images and not updating images during build. Thoughts?
I didn't address the implications of software vulnerabilities in respect to other mitigation techniques, however, as it's far outside the scope of the article. I probably should at least add a second addendum though. I'll work on this soon. Thanks!
Analysis is easier because you already have a running agent that you can
remotely query about deployed software. With regular OS you need to provide
such an agent.
I don't know why it's easier to mitigate risks, though. Maybe just because
it's easier to run the analysis.
> Analysis is easier because you already have a running agent that you can remotely query about deployed software.
Not sure I buy this. Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable. I still need to build something to actually scan the images.
Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that, and the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker.
That's correct, vuls queries the package manager for installed packages, versions, and changelogs. It then compares the CVEs found in the changelogs to NVD.
There are certainly flaws in this approach; it's one of the reasons we intend to support multiple scanners. We started with vuls because clair wasn't released yet and we wanted to support more than containers.
> Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable.
If you can query what images are running, you can tie it with list of deployed
software. Then you can compare that list with database of known
vulnerabilities; obviously, you'd do the same if you were assessing the host
OS without Docker. What's easier is that you already have an API that can be
called remotely.
> Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that
But you need to get to each of these hosts somehow and get the data out of
package manager, so a report can be prepared. This is the part that makes it
easier to assess what you have in the case of Docker. Then there is also
software that was not installed with OS-supplied package system, because
programmers somehow dislike those and work around them with virtualenv or
npm-du-jour.
> [...] the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker.
I haven't read the article, but most probably you're right.
The conversion of package version numbers to vulnerabilities is perilous and incredibly complicated. That's one of the most significant challenges that we want to solve, which is even more pressing considering how badly the CVE ecosystem is breaking down.
Indeed. Auto manufacturers don't sell vehicles, they sell debt. I've heard this is a good reason to withhold that you are paying cash at a dealer until the last moment and work the best deal you can as if you are going to use their financing. They are much more interested in making a loan than making a sale.
I just bought two new cars, a Chevy Volt and a Mazda CX-9. The dealers couldn't care less how I was going to pay, nor whether I purchased or leased. They barely even tried to sell me extended warranties.
In fact, Mazda gave me a $500 incentive to borrow at 0% for 5 years. My GM loan was also 0% (but no incentive). So obviously they aren't making anything loaning me money.
Further, I find it hard to believe there's no or slim profits in the sales. I think I did a pretty good job negotiating. I don't even mind disclosing the numbers.
The Volt had an MSRP of $40,325. I managed a $38,258.25 sales price + $1147.75 tax + $94 tag less $1000 rebate for $38,500 out the door. The invoice on this car is supposedly $38,651.
The CX-9 was a similar situation, with an out the door price below invoice.
Both dealers I purchased from were in fact a bit out of town and had to secure the vehicles from other area dealerships. They knew I wasn't likely to use their service departments (each is almost an hour away), so I doubt they cared about any more than making the sale. The sale alone has to have been profit motivated.
Now, maybe individually they didn't make a lot of money on these sales. But it has to be the case that they are making money on their total sales volume. Maybe they'll take a loss on a sale or two if it puts them above a quota which gets them a huge bonus.
These dealers are obviously costly to operate. They have a lot of real estate and the show rooms are beautiful. They hold a ton of inventory for months at a time. I just can't believe they could exist on the slim margins they claim they make on each sale. I would be shocked if they aren't easily clearing 20% or more on average on sales alone, even on deals like mine.
Franchise stores net 2-5% before taxes on "big" numbers. $20mm yearly rev for a smaller, rural, domestic franchise to multi-billions in yearly rev for a nationwide autogroup.
As mentioned, most profit is generated from service and finance.
Both of these cars you purchased are from high volume mfgs. The dealers made holdback money plus the sales count towards yearly tier incentives.
Electric vehicles in particular pose a challenge to the service-derived revenue stream due to lower maintenance costs, so much that Audi's US President urged their dealers to focus on selling value-added services like home EV charging station installations to make up for the lower service requirements of their upcoming EVs:
I started with Edmunds and True Car. This turned out to be a waste of time as in the deals I got through those sites were just okay.
I also did some research on gm-volt.com and mazdas247.com to see what other folks claimed to be getting in terms of pricing.
Eventually I contacted a bunch of dealers that I knew had the car I wanted (Mazda and GM's web sites will show you all the inventory in an area) via email and asked them what their best price was. The dealers near me which had the cars on their lot didn't offer me the best prices though.
In the end, I got the best prices (and the most pleasant sales experience) from two dealers each about an hour from home. They were happy to negotiate via email. Even though they didn't have the specific car I wanted, both claimed they could secure it from other dealers, which they did. Both of those dealers had the most aggressive price up front and I was able to get them each to come down a bit from there.
As far as I understand, for every sale dealers will get a "rebate" from the car company. This obscures even more the relationship between the MSRP and the dealer's cost. I think it also works as something of a tax dodge for the dealer by shifting profits late into the fiscal year.
not just holdback, some manufacturers offer hidden stair-step incentives that once hit, are retroactive to all vehicles sold that month. That's why you can usually get the best deal towards the end of the month, when the dealer is willing to sell below cost to get that hidden incentive, sometimes worth over $100,000 depending on volume.
This American Life made a whole episode in a dealership which had that exact problem: they had to sell 129 in a month to get a bonus from the manufacturer.
"The last day of the month continues and the truism is accurate: some people get great deals because it’s the end of the month and they have to hit their goal. When you look at the numbers, the average car they sell in the last two days actually loses money."
I haven't experienced this, I've actually had good luck doing basically the opposite. Go in with quotes already from my bank/credit union(s), tell the dealer "if you can beat 2.2% [or whatever] I'd be interested in your financing", let them decide if that's worth it to them, but still negotiate bottom-line total dollar amount, not monthly payment, as if paying cash (since outside loan = cash, to them).
Its interesting to note that GM Financial is a rather new addition to GM. They sold their original vehicle financing arm (GMAC) during their bankruptcy as did Fiat Chrysler.
IIRC, Jet was handing out equity in lots in order to hide the percentage of equity granted. This typically means a) They want to hide how little piece of the pie you are getting b) They are going to do further shady stuff like reverse splits, clawbacks, etc
Edit: The employee in this thread is still working so not FU money. Maybe "FU for a year while I travel the world" money.
This was a hack I used on an eventually failed software venture. We were in an incubator and had about $10k and the start of a pivot. We hired 3 contractors to build an MVP in about 2 weeks. We focused on the core functionality of the product. Since we used Rails we also were able to use a module that gave us a nice admin UI around our data model. This let us do the data entry for pilot members while we got feedback on the core product. Since we were providing a way for vendors to sell products with complex facets (prices in multiple currencies, descriptions in multiple languages, complex product availability etc) we could control the data entry and also avoid building complex wizard UIs for users that surely would be given up on with our limited value prop at the time.
Thinking back on that hack I think it is definitely something I'd do again.
You just listed a bunch of reasons why your Enterprise should not be using Docker.
EDIT: I did not realize it was per node pricing. I take back mostly everything I said below. I hope that ultimately when Docker does provide 3 years of support, you'll be willing to pay up.
Look at the pricing, even the biggest Enterprise plan is $2000/yr. This is aimed at small consultancies, startups and small businesses, etc that are tired of sending their developers into the docker github issues to log bugs and argue features.
When Docker adds a plan that satisfies your Enterprise, you'll be paying typical Enterprise prices that will be at least an order of magnitude larger than the current biggest plan. Hopefully you are able to put your money where your mouth is.
Of interest, GE is a Cloud Foundry Foundation member and a founding investor in Pivotal. They have a fairly engineering org working on their IoT-oriented version, Predix.
Docker has always been freemium. Not sure why you'd fear that even if it weren't the case. IMO freemium OSS is a good thing, this is how "free" software gets funded.
As a lawyer and tax accountant, do you see a flaw in the professor's approach? Any domain expert insight here?