That's the plan! The incumbent SaaS providers are effectively charging a premium over the underlying storage. Their business is really reselling storage. Removing that premium via a self-hosted system then greatly reduces the need to structure your applications to fit the cost of monitoring it. This also means that any negotiated discounts and features they may use (e.g., S3 Standard-IA) are also applicable to data in Opstrace.
We will also have a blog post about bad UX in a couple weeks… stay tuned. What are some of your biggest gripes about UX?
Just to answer the question about what metrics are included, you can write and read any kind of custom metrics and log data from your applications, and have to build useful dashboards yourself. When first deployed, the user tenants (you can create any number of tenants to partition your data) are empty (you start with a clean slate) and ready for you to send any metrics/logs to it. You also have to add your own dashboards to interpret the data you've sent.
Opstrace does ship with a "system" tenant designed for monitoring the Opstrace system itself. This tenant has built-in dashboards that we've designed to show you the health of the Opstrace system.
Incidentally, having sharable "dashboards" across people/teams/organizations is something we are also working on, so people don't have to re-invent dashboards all the time.
Hi, this is Nick Parker from the Opstrace team. I personally have my own on-prem arm64/amd64 K3s cluster, including a basic 4-node Minio deployment, so I’m very interested in getting local deployment up and running myself. We’re a small team and we’ve been focusing on getting a couple well-defined use-cases in order before adding support for running Opstrace in custom and on-prem environments. It turns into a bit of a combinatorial explosion in terms of supporting all the possibilities. But we definitely want to support deploying to custom infrastructure eventually.
This looks like an interesting product. We're figuring out our monitoring stack - but have also found Loki/Grafana - and we're looking at Victoria Metrics rather than Cortex. Our hope is that the combination will turn out to be able to scale down as well as up, and be possible to fit in with Docker swarm/compose on-prem and at digital ocean. Also looks like vector might be a good option for collecting data.
Will keep an eye out, to see if optrace might be a fit for us.
Mostly the promise that they do mostly the same, but vm uses less resources. I believe vm has slightly less resolution/fidelity - but not so much that we expect it to matter for our use-case.
But we're still implementing it - so we might still run into surprises.
Jan-Philip from Opstrace here, good morning. Would love to hear more, after all, when you know more :-). By the way, we had been asked about VictoriaMetrics before, here: https://github.com/opstrace/opstrace/discussions/98.
Good to know, and thanks for confirming. I totally get that supporting all combinations can be a real challenge. I guess containerization helps, but that's becoming it's own smorgasbord of almost-compatible bits.
Yeah, anytime I hear "on-prem" deployment I think of my previous experience with getting a product deployed across a lot of different K8s environments. At the surface there are ostensibly common APIs, but the underlying components (networking, storage) are not necessarily interchangeable. There may also be custom policies around e.g. labels, SecurityContexts, or NetworkPolicies. In my own K3s cluster I generally just manage the YAML specs for the deployments by hand, since I’ll often need to e.g. specify the arch constraint to run against, or ensure that it’s running a multi-arch image. It’s a really interesting problem though, and it’s something that we’re targeting.
So, I rarely see eg Java code that actually handles the exceptions it receives. Usually its just "Oh, I got an exception, so I'll print an error (or silently fail) and blindly keep going".
Given this, I don't see how Go is any worse with respect to sloppy programmers. They'll Always Find A Way.
Also, why couldn't your second example be nested? It seems like either of those two examples could be structured identically to the other.
I find Java exceptions quite good for cases where you want to fail at a much coarser level than the specific problem, but finer than the whole program. E.g. my previous^2 job was essentially a message-processing system; it had a bunch of loops that took messages off queues and processed them one at a time. If processing any given message threw an (uncaught) exception, it marked that message for retry or as failed and carried on.
You could certainly argue for handling each message in a separate process a la erlang, but this approach worked well for us.
I think checked exceptions were a mistake (IIRC Gosling agrees), and Java could do with better support for multiple return values (which exceptions get abused for), but I like Java-style runtime exceptions.
> You could certainly argue for handling each message in a separate process a la erlang, but this approach worked well for us.
I'm pretty sure you wouldn't do that. You'd have a shallow tree of processes, each leaf process would be tasked with doing message processing e.g. provided by its supervisor. The supervisor would "manage the queue" so to speak, and depending on the semantics of the queue it would have 1 to n children; and it would be tasked with marking failed messages when a child process would blow up (and restarting a new child).
Modelling messages as processes would likely be impractical.
Errors should never pass silently
Unless explicitly silenced
The problem with go is that you have 3 error modes:
1. Explicitly handle everything
2. Implicitly silence sometimes
3. Panic/recover explodes sometimes (who knows where/when?)
Mode #2 is dangerous.
Java/Python give you 2 only modes:
1. Implicitly explode on error.
2. Explicitly silence sometimes.
Where both modes aren't inherently dangerous, i.e. they won't directly cause undefined states to execute.
--------------------
Concerning the nesting in my examples - I'm used to the style of C programming where failing is mostly handled by a return as to keep the program as readable (and thus flat) as possible. So pardon my french but I assumed "// do something" would somehow prevent further usage of 'f'.
Note that the Go example, although tedious, isn't bad in cases where you really do need to check every single possible error.
I think this is not what you're actually seeing. When you get an exception there is rarely much you can do other than log the error or alert the user. It is much more important what you do not do in such a case - you do not let bad data flow into your program, and exceptions are great at preventing that.
No, the patent claims the identifier is derived from the data, and only the data, which a file name is not. It also have several other constraints and steps. (i.e. a patent describes a a system as a whole - the fact that individual parts of a patent is in wide use elsewhere doesn't necessarily mean those systems infringe or invalidate this patent)
Wait. This isn't true. Most filesystems don't have an algorithmic identifier for the data being stored. They do often have checksums, but that's different.
You could argue that most book titles fall under this as well, at least conceptually. And the Dewey decimal system.
In fact, before the growth of the internet, Identifying and Requesting Data in Network Using Identifiers Which Are Based On Contents of Data would sound almost exactly like a long winded academic description of finding a book through the public library inter-lending network.
An investor is best served by keeping things as simple as possible. The most they should be concerned with is the simple ratio of stocks/bonds/cash that meets their risk tolerance and time horizon. This can be easily determined through some simple survey questions[1] or comparison charts[2]. Most fund companies even offer target date funds, which make this simple decision even easier. And by keeping things so simple, the investor is discouraged from doing harm to their investments by repeatedly transferring it between the latest fads, something which advisers are definitely prone to do.
Basic investing is only made to look complicated by people who depend on selling expensive advice and guidance that most people don't need. Paying an adviser 1% per annum means you lose 30% of your balance in 40 years, not including any bad decisions they make with your money in that time.
I dunno, you can buy 5 $35 raspberry pis for the price of one $200 pandaboard. $200 approaches the territory of being plausibly enough to build or purchase a full PC.
I was quite disappointed in my RPi buying experience, living in the US. I'm still waiting for it to arrive (despite preordering the minute the sites came back online). They notified me that it was being shipped a couple weeks ago, told me that shipping would be about 12 weeks. The exchange rate threw me for a heck of a shock, with my RPi costing about $50 minus shipping.
The RPi might be the soup du jour, but it's an incredibly frustrating device to get your hands on. At least the Pandaboard can be placed in my hands; for all I know the RPi might not even exist at all.
I have 2 of them, one each from the 2 places taking preorders on day 1 and I wasn't first in line or anything. I got both of mine about the middle of June and they didn't cost any more than expected.
I got mine from RS, preordered the week it went on sale. My cousin ordered his a month later and got it last month. 12 week shipping to the midwest. Crazy.
The price difference is due to 35GBP = 55USD currently. To quote the email I received: "Delivery Type Desc Standard Delivery (Despatch expected within 12 week(s))"
I love my TI-89, which I got ~7 years ago for college physics/astro classes, and still use fairly often when the need arises, typically once or twice a month. I find the interface of a physical calculator to be far superior to a more general purpose machine when facing the tasks its built for.
However, I also think they're way overpriced for what they are. I think a lot of the price is just 'because we can'.
They've set up a great lock-in system. They've bought off all the schools and teachers to get them to require students to use a specific TI model, and then they get the schools to buy textbooks that are written to use the TI calculators, with examples that give keystroke-by-keystroke instructions, and sample programs written in that model's dialect of BASIC. Sometimes they even get the standardized tests to require a specific calculator.
It's a great deal for lazy teachers: not only do they not have to teach their students how to perform the calculation, they don't even have to teach the student how to use their calculator to do it. If a student wants to use a different model, they're on their own. They'll have to learn the TI BASIC anyways, because the textbook doesn't even try to do a decent job of describing an algorithm in any other notation.
In most cases, breaking TI's monopoly would be as difficult as, and possibly require, busting a teachers' union.
I've heard the other reason is their math libraries. I don't know a whole lot about the calculator industry, but I've been told the number of companies with good embedded math libraries is very small, and the cost of developing one is prohibitive.
This adds big barriers to entry. You can't write your own libraries, and you can't use more powerful hardware to compensate either- TI's calculators cost them very little (the popular TI-83 uses a CPU designed in 1976), and will shove you right out of the market with their huge profit margin.
The result is a dramatically increased page load performance that only works between Chrome (as it includes SPDY support) and Google’s servers (which supports the features for Google sites.)
Reminds me a lot of MS's strategy of adding incompatible features to existing standards.
Embrace & Extend is a well known, very destructive mechanism for subverting standards.
Enhancing existing standards with experimental extensions is a well known very useful mechanism for improving widely used standards.
As with anything to do with technology you need to look at the details to determine exactly what is happening on a case-by-case basis.
Just saying "that sounds like MS" isn't useful without examining the details. For example, many of Microsoft's extensions to HTML were very useful (eg, XMLHTTPRequest), whereas others weren't. It's a case-by-case thing, and asserting this is always bad is a very shallow interpretation.
TL;DR: Details matter. Experimenting by extending standards isn't always bad.
Yea, I have to come to think that embrace and extend is not the worst thing MS did. For example, extending ODF would be far less bad than creating OOXML.
Extending ODF was not possible because Sun would not allow it. Sun's IP licenses for ODF effectively gave them veto power over attempts to add things to ODF that they did not approve, so that was the end of that. Sun's position was that ODF would support exactly the feature set needed by StarOffice.
If you ignore IBM's and Sun's massive FUD campaigns against OOXML, and actually compare the specs, you'll find that OOXML is not anywhere near as bad as they claimed, and in many ways is better than ODF. ODF does have nicer markup--I'd much rather read or write by hand an ODF file. On the other hand, ODF is incomplete in major areas, and other areas are imprecise. (Sun and IBM actually tried to use this as a point in their FUD campaign, slamming OOXML for having too much detail).
It's seems likely that Sun's IP licence was specifically written to stop Microsoft from doing its well documented embrace, extend, extinguish routine on ODF like they did to Sun's Java. Instead they just emrbraced, extended and extinguished the entire idea of a standard XML office format. Nice work.
Weirdly, Microsoft seem to have incompatibly forked their own OOXML format and are in no rush to fix that now that they've seen off the competitive threat posed by ISO standardisation of a competing format.
StarOffice and Microsoft started work on XML formats at around the same time, and most of the subsequent histories are largely parallel. There was no EEE here.
I'm a long way from being an expert in the area so I won't comment on this exact situation, but an overall thought: the difference between MS and Google is that MS wanted a monopoly and were generally quite sloppy, whereas it's in Google's interest to have a faster internet for everyone, not just their users, plus they have the ability to push for adoption of features developed for their browser/servers, which could lead to other browsers, and servers (would it be Apache/etc. that would have to implement it?) adding SPDY support.
How is that different? MS wants marketshare, Google wants marketshare, faster internet for everyone is just a means to an end: more people using Google services. I'm sorry for not buying into the Google-hype, but keep in mind they're a business like everyone else and they are in it to make money. If you ever need proof that Google is doing this for money like everyone else, just take a look at the history of their advertising services.
I'm not saying that Google isn't doing this for business reasons - it just happens that in Google's case, they benefit more from all browsers being better than trying to make Chrome kill off other browsers.
This is similar to Microsoft happily pushing and supporting new bus/interface/port standards to allow many various hardware companies to bring newer, better, faster hardware to the consumer.
It wasn't because they were nice or had the consumer's best interest at heart. They just wanted PCs to be faster, because they had a monopoly that sat atop PCs. So they benefit when PCs get faster, get replaced and stay ahead of would-be competitors.
they were actually adding it over a well-defined extension point (ActiveX instantiation). Not by extending the existing spec (JS/DOM).
That happened later once the usefulness of XmlHttpRequest was noted and other browsers added it directly to their JS support before it was formally specified.
So this is exactly the way to extend (by using clean extension points) that Google was using with SPDY. This is different than, say, implementing a <marquee>-Tag directly into the HTML renderer which doesn't provide a nice extension point.
Google's bottom line is a result of the volume of internet content consumed. Their presence means that no matter where you go, you encounter Adsense ads.
Google wants the whole web experience to be faster. They don't benefit in locking you in. I imagine Apache/Nginx/etc will all have SPDY support in due time (while still defaulting to HTTP or a hybrid setup) and it will be yet another nice enhancement to the web experience.
BTW, if you think what the IE monopoly did to web standards was bad enough, look at what the Netscape monopoly did to web standards. Saying that Netscape had a bad track record of following them would be underestimating the impact.
We will also have a blog post about bad UX in a couple weeks… stay tuned. What are some of your biggest gripes about UX?