"That said, some forms of electronic payment more closely
mirror physical currency. In particular, crypto-currencies and other digital
currencies are generally unregulated and do not create clear records of
transactions in a form that can easily be used to identify the parties to a
transaction."
Using the `golang:1.10-alpine` image to run your binary would defeat the purpose of a multi-stage build, since it includes everything needed to compile Go and weighs in around 376MB. The `alpine:3.7` image is about 4MB.
edit
I misunderstood the parent, they meant to use `golang:1.10-alpine` as the build image, not the run image, as in:
FROM golang:1.10-alpine
COPY . /go/src/bitbucket.code.company-name.com.au/scm/code
WORKDIR /go/src/bitbucket.code.company-name.com.au/scm/code/
RUN go build main.go
FROM alpine:3.7
RUN apk add --no-cache ca-certificates
COPY --from=0 /go/src/bitbucket.code.company-name.com.au/scm/code/main .
CMD ["./main"]
This is really common in Australia - I've found the biggest giveaway of a fake-craft brand is that the alcohol content is generally 4.8% (which just happens to be the governments definition of a full-strength beer).
In the US, where I buy Japanese beers, all are either brewed in the US or Canada under license. If it's brewed in Canada, it's marked up as imported. I doubt it's any different in other countries or for other brands.
The biggest reason would be the "native" interoperability. No FFIs because while you could call it a language it's more accurately syntax sugar.
Another reason with Rust at least. Rusthon can make the same memory guarantees as Rust.
Personally I wish this was done with Ruby.. But then again I'm not writing it myself, so I can't really complain.
A random last thought, it would be really something if Rust could formally prove its memory safety and then push that whole system of lifetimes and borrow checks into LLVM or a similar abstraction on top of LLVM. Because Rust as a compiler target is very interesting but it wasn't really built for that.
You are one of few concerned with Python3 targets.
Pyston, PyPy are all mostly Python(2) projects. PyPy3 does exist, but it's considered beta and not recommended for production use as PyPy is.
Python(2) code/libraries will mainly survive on PyPy/Pyston going forward.
With stuff like Nim and Rusthon, I think something like those will carry the torch forward after Python(2), rather than Python3.
I've witnessed this first hand - we recently started rolling out measured goals in our warehouses. This involved staff getting set daily goal counts for certain tasks (products shipped, products put on shelves etc.). As soon as we rolled out metrics everything that wasn't measured became a low priority. For example, we were not measuring cycle counts (stock take) so immediately the number of cycle counts plummeted, which increased our out-of-stock errors. We had instances of staff hoarding incoming shipments from suppliers at their workstations in order to get higher rankings.
Overall the warehouses went from being generally efficient to extreme performers on measured metrics. I think metrics can be clearly powerful, but you have to be very careful about what metrics you choose to implement.
I really wish this was taught more in business school: that metrics/productivity is subject to the Observer Effect (http://en.wikipedia.org/wiki/Observer_effect_%28physics%29) too: that the act of observing for metrics will change the underlaying system.
If underperforming on your metrics will cause some pain, humans in general want to avoid pain, and you ARE employing smart people who are paid to solve problems and do analysis ... well, duh some metrics gaming will happen: people avoiding pain.
Probably this will have an opposite affect than what the measurer wanted: people hording things/information/output specifically to improve their metrics, people working around the metrics (outside the managed systems), or essentially spamming the system ("oh you found a bug in my you're reviewing? Can you file a new bug on this?... so my closed bug count for the week goes up...")
A long time ago, in western Europe, kids wouldn't go to school if they were sick. To check if they were sick the mother would check their temperature with an alcohol thermometer. Of course the kids understood the goal and used the night lamp to get the appropriate temperature displayed to skip school.
When talking about metric in corporate setting I like to remind everybody that I have a strong suspicion that the guy who invented the thermometer also discreetly invented the night lamp.
(most of the context is disappearing: blinds that force you to use the night lamp in the morning, alcohol thermometers and incandescent light bulbs)
I did the same. The top of the thermometer exploded as the mercury inside got too large. Apparently, the thermometer was not designed to measure freshly made tea.
The OSVDB website contains no signup page for commercial access. No pricing either, purely sign up via contacting someone. From my experience whenever I see this, I just refuse to use the service and look elsewhere. Contacting someone is annoying and opens you up to repeat sales calls. Perhaps they should make commercial API access easier to access rather than complain about scrapers.
I have to disagree. As creators, we should expect to see the behavior our designs encourage.
The fact is, if it's harder to buy something, would-be buyers choose another route.
Imagine something of trivial value that was very arduous to obtain. Say, the scores to last weekend's football game are only available via sending the NFL 2 cents taped onto a postcard then getting a user account and password back in the mail. Yes, you could apply for an account and who cares about the 2 cents? But most people wouldn't and who could blame them? There'd certainly be a market for pirated 'score data'.
But, if you just put ads on your site (the NFL does), voila! You make the same amount of money and people are happy to use your service. Netflix, Hulu, iTunes Store and Spotify all get this. If you make it a pain to do something, you can't feign surprise when everyone goes around you.
Is it legal to circumvent something just because it's arduous? No. Is it ethical? Not completely, but downloading pirated football scores wouldn't keep me from running for office.
Perhaps a method used exclusively by very large companies is that way for a reason? Of course purchasing by talking to someone on the phone is extremely difficult. The only reason people sell that way is to make sure they can hassle you as much as possible during the sale.
Apropos of nothing: customers often have an exaggerated notion on how important it is to e.g. an enterprise software company that that company land their account.
A conversation I've had a few times:
"We need it to do $THING_IT_WON'T_DO."
"In that case, it probably isn't a great fit for your needs."
"You don't understand. I won't buy it if it doesn't do that."
"I think I do understand. That's fine. You might consider trying $COMPETITOR, although you should know their minimum spend is $1,000 a month."
"That's outrageous. You have a $29 plan."
"Yes. So you should go with the competitor if that requirement is worth $971 a month to you."
"No, I want to spend $29, but I absolutely need that."
"I understand where you're coming from, but we do not offer that feature, and if we did, we would charge prices close to what our competitor does for it."
"You're not working with me here."
"I'm trying to find a resolution which works for you, but including that feature at $29 doesn't make business sense for me, so I won't do it."
"Put me on the phone with your boss."
"I'm afraid that isn't possible, as I sort of run things around here."
"What sort of businessman turns customers away."
"You're not a customer. If you were, you would be purchasing a product I sell for the amount I sell it for. That isn't happening. That's fine. Have a nice day."
That's fine. 'patio11 has lots of stories about that.
However, the lack of up-front pricing data isn't being used to justify "I won't do business with you." It's justifying "I'm going to take all your stuff anyway."
Even ignoring the difference between taking something for personal use and taking something for commercial use (as that is a distinction that does not affect the legality of the matter) "because other people do it" is not a valid defence.
That's exactly the problem that GP is talking about.
McAfee were just being the usual assholes, but the first guy mentioned in the blog post could have been converted into a paying customer if the pricing scheme were clearly outlined on the web. Since "Contact us" account tiers are usually reserved for the very high end, he probably assumed that it would cost him an arm and a leg.
It shouldn't be too difficult to come up with a handful of moderately priced account tiers, each targeting a different type of customer, as well as an open-ended tier at the end ("Contact us") for those with special needs and deep pockets.
So many times I say this to people. Sometimes the reason people aren't buying is because they can't find the price, and aren't willing to pay the mental price of talking to a sales person to find out.
I understand the sales psychology in making sure you enter into a proper discussion with people to make sure their needs are right, and extracting the maximum consumer surplus from them. But there is a non-trivial pricing point where this makes sense, and by not having any anonymous-sign up, you're cutting off your sales curve below this point.
I think it's very easy to convince yourself it's easier just to sign up customers over the phone, but doing so without at least testing takeup of simpler tiers is an incomplete picture.
I get this line of thinking if your you can sell your offering for $100 bucks a month. But what if your minimum offering is $2500/mo? Correct me if I'm wrong, but I've yet to see a company - that only sales through enterprise - put up a sign saying where their plans start at $2,500.
In most cases I don't believe these services are forcing customers to talk on the phone because they think they will convert them. Chances are that sign up isn't as easy as a 1-2-click, and involved set up and understanding of the customers needs is required before services can be rendered.
If your signup process is understandably complicated and you require a minimum commitment of $2500/mo, then it's probably okay for you to tell potential customers to give you a call.
If your signup process can be automated and you only charge $25/mo, and you still tell people to give you a call, then you will lose business because 1) the friction of a phone call is worth more than the difference between your offer and a competing offer; 2) it's impossible to tell whether your offer is worth the friction in the first place, because your pricing is unknown; and 3) people just assume that you'll charge $2500/mo because that's the usual price point where people say "contact us". If someone else comes along and offers an inferior product for $35/mo, they'll get all the business because monkey psychology.
Yes, that's what I am saying. There is a pricing point at which having a customized sales process absolutely makes sense.
What I am saying along with that is that - by doing this - you're ignoring a lot of the market at (or even just below) your price point. That might be OK - as long as it is a conscious decision to do so, including acknowledging that your market is completely above that point.
In the case being discussed here, it would seem that there is an interest below this price point.
During University one of the projects we were given was to write a regular expression parser and evaluator. From the moment that project was complete I have never had trouble understanding regular expressions. I thought it was an excellent way to learn them.
Having out of date packages on production servers is also dangerous. It really depends what you consider your biggest risk to be: downtime vs getting hacked due to an out-of-date packages? I personally would take downtime, but every place is different.
A check for necessary updates should simply be part of someone's regular, preferably daily, routine. It's a basic cost of doing business.
The manpower necessary is not enormous. Any particular security update has a relatively small chance of requiring prompt installation on a particular production service. On the unusual day you're struck by lightning, you pull out the relevant emergency plan and begin executing it.
Remember that a lot of small to medium sized websites are maintained by part time freelancers and don't have anything resembling an ops team, there's nobody being paid to do the day to day running of the servers.
In such a situation it's probably safer to at least have automatic scheduled patching against deadly vulnerabilities and accept that occasionally that might break something.
You're positing a scenario that shouldn't occur in the first place. Such a website should be on a shared or managed hosting service, or alternatively, there are companies that will, for a reasonable monthly fee, perform basic routine maintenance such as this on your servers.
If you want to completely mismanage a server you depend on for your livelihood, I can't stop you. All I can say is you're doing it wrong.
"The message will be accompanied by a short video message by Wikipedia co-founder Jimmy Wales, and images required for the re-creation of fundraiser banners."
The thought that a few million years from now an alien race will encounter a message from Jimmy Wales asking for money is fitting for Wikipedia.
https://www.treasury.gov.au/sites/default/files/2019-07/expo...