I'm pretty sure that an exhaustive answer to your last question is "the history will tell" with additional assumption that all those drivers would be deployed in many production environments.
this is almost exactly my workflow, but before clicking on a first box I additionally wait several seconds until the page loads. Also, sometimes I extend that workflow with silent cursing and contemplating self-harm
>It is extremely useful for setting up separate development instances for your projects
this. and not only the ability to have different software and versions for each project but also the ability to more or less match the production environment in your dev container for each project.
This sounds interesting to me! I actually thought about something relatively similar with the intention of creating js-based renderer to make it web browser compatible. I was also contemplating the idea to put semantic data into a separate structure, similarly to schema.org data in json-ld format. While this is probably worse from the editor point of view, the advantage would be more clear and more human readable content since the semantic tags would be omitted. This could also save some bandwidth if client software could fetch only the part that it needs (for instance if a given reader does not support semantic tags parsing it could download only the main content, while search engines could download only the semantic part).
The problem is that thinking about that for a while is all that I've achieved so far :)
In essence this is one of the principles, the thing is the emails don't need to be perfectly identical, just identical-ish with the identicalish matching implementation being not public (as this would immediately lead to spammers adding just enough randomness to whatever they are sending)
That seems extremely interesting to me! Would you care to tell any details about that or is it covered by NDA? I'm guessing that's something HFT related?
While not trying to defend PHP (well, tbh I'm trying but just a little), but there is a phalcon framework ( https://phalconphp.com/ ) which is written in C and works as a PHP Extension. While the rest of the code still is in PHP, at least the framework bits including a lot of boilerplate are much faster that way.
That's obviously true, however a minimized version will require less memory and slightly less cpu-cycles* to compress and, on the client side, it requires slightly less resources as well
I do realize how insignificant difference that would be
* then again not much of a difference since the DOM tree itself would consume orders o magnitude more mem.
While you are obviously right, I still believe that the MVP one weekend project I described in parent post would still cover a large fraction of use-cases. You could then improve on that and add some "minor" (minor in the sense of dev-time) improvements like syntax highlighting using some free (as in beer) libs for that.
I am not trying to imply that I could "clone" Slack over the weekend by putting together ircd+elastic and then adding some JS cruft on top of that. But I do imply that just that would be enough as an MVP and as something that would make usage of self-hosted IRC possible for a wider, non-technical audience. I also believe that this itself would cover the functionality actually used by many slack users (at least my personal anecdata from 8 smallish companies supports that)
And I also can't stress this enough: I am not trying to say that Slack was created over the weekend or devalue a really impressive and massive effort they've put to get the scale, the functionality and the UX.
While don't have any info or even anectada about the other, JIRA is even more bloated on the server side - we had JIRA hosted on premises and it was used mainly for tasks and tickets in a team of 5 people. This "metric" (team size) limits the amount of tasks/tickets that would be processed. Anyway, the JIRA itself needed 2 cores and 8 GB of ram just for that. This is really even beyond absurd.
while I don't remember how much memory did BitchX use, I do remember that a whopping 8 megs of ram was enough to run mIRC with 20+ channel tabs without serious glitches. And those precious megs were used not only for the irc client but also for the OS itself.
No, of course not. Neither adding some minor extra features (that make a huge difference for the end-user) nor profiting from it is bad. My concern was that there is so much good tech that is not being utilized just because it lacks enterprisey look and marketing attention.
Take slack as an example: ircd with logging enabled + elastic search/sphinx/lucene + web frontend (use any existing web irc client and integrate that with elastic search results). MVP really seems as a one guy one weekend project. And that was lying underutilized for decades. While my original comment was just a snarky remark, I really think that there are other areas where such a (relatively) simple MVP could allow huge productivity boost to many businesses and allow them to use an existing tool that right now is just too hard/too complicated to use by a wide audience.
And of course the market will reward those that will find the right solution and come up with a great UX improvement to that tech. The hard part is creating the GUI that is both efficient and easy-enough , and the hardest part is of course finding the right tool and the right problem to solve.
(edit: formatting)
I used to work for a relatively small dev-shop (9 persons) and we had two independent internet connections from two providers to avoid such problems. This was because done that way because there was only one fiber provider that wasn't really reliable (3+ hours downtimes every 1-2 months) and mobile tethering wasn't really an option as well because of nearby powerlines that made the reception quite a problem - to the point where our sales guy had to go outside the building during some calls. Luckily there was a second ISP - not really fast (10mbps was the best they could do) and quite expensive (we've paid more than twice more for that 10mbps than for a gigabit fiber), but still cheaper than having 9 people not able to work while waiting for the "main" ISP to solve their problems.
Yes it has and it is a great thing - hopefully no messages would be lost assuming that downtime is relatively short. This still does pose a (possibly minor) problem when some mails are urgent.
It seems that you could take any old-school internet tech, add some flashy GUI, slap "for enterprise" label and you get a great and popular solution that solves the problem noone ever could solve. Maybe it's time for gopher for enterprise
While email as a whole is indeed federated, email service for a single company is usually not, that is you have a single provider and when that provider happens to have technical issues your email might be down. While obviously you could use other provider (or even free email) almost immediately to send emails, you will not be able to receive/access emails that are sent to your primary address/domain until the provider resolves their issues.
Thankfully github is not a walled garden and repo can be moved to any other public or self-hosted git (well, at least the code itself). Or, as someone already suggested, use an external service/server that pushes the commits into git(hub|lab) repo.
Git also seems to be relatively easy to work in a federated ecosystem - the only problem to be solved is read/write access in such environment.
Agreed, there is absolutely no point going further after reaching a certain reliability level. However, one thing is eliminating risks, the other is limiting the consequences of said risks. I strongly prefer 99.9% reliability where that 0.1% means some insignificant problem over 99.99% reliability where the remaining 0.01% means total disaster.
My point is that doing "too much" automation gives diminishing returns (which is not bad in itself), but might also disproportionately increase the consequences of that 0.xxxx1%
>make incidents actionable by creating tickets automatically
not really a serious concern, but what happens when ticket automation goes down? If all the problems are auto-reported, in a form of tickets or tasks, then if that somehow breaks down it might take a moment before anyone notices, especially if reported exceptions are rather rare. If it is normal to have tens of tickets every day, then problems with ticket creation will be noticeable almost instantly, if they are very rare - then not so much
The second issue with automated exception tracking is that you loose the "huh, this is weird" mechanism that works when actual humans go through logs or reports. While any tool will of course be orders of magnitude faster and also probably more accurate, by relying solely on such automation an opportunity to notice some "weird"/not-typical entries or rare/unexpected sequences of those might be missed. Then again in most cases - I guess - simple statistical analysis might be a good substitute. And that can be automated.
(edit: formatting)
Yes and no. While it solves users/audience problem for alternative platformm, there is another barier of entry: bandwidth costs. I recommend anyone to do a simple math excercise of simple multiplication:
size of 20 minute 2K video * 50'000 views * price per GB of traffic on your favourite cloud/hosting platform.
To make the excercise more interesting now multiply whatever result you got by the number of videos your platform is supposed to host. Assume this number to grow each month. Also assume that some users will want 4K.
I'm not sure if using hidden services is considered a viable solution here on HN, but it seems to to me to be the solution. Don't know any video streaming services but I assume that such sites already exist. The main selling point would be relative difficulty to take down a specific video through a legal action. I assume that youtube takedowns are either results of complaints/legal threats that they have received or a preemptive action to avoid such legal problems happening in future, i.e. their legal department assessed that the risk of such motions in future to be likely. On the other hand, considering bandwidth requirements for video streaming deanonymization of such service appears to be relatively easy, hence possibly some service centered around ipfs would be viable.
>cryptocurrencies being artificially constructs doesn't sit well with some non-techies
fiat currencies that non-techies do use are also artificial constructs. There is however the gold bars in federal reserve/national bank myth so the fiats appear as non-artificial to many people. Possibly that makes the difference. Or, more likely, people use fiat currencies since forever and don't really think about that.
I believe more "the thing that exists for ages and I'm familiar with" vs "the new thing" thing.
Anyway I'm not trying to invalidate your point, my experience with talking to non-techies about cryptos is more or less the same as yours
you can increase playback speed. 1.1..1.25x speed is usually OK in terms of ability to understand the speech while saving several percent in time. Sure, the transcript would probably require significantly less time to read and is my usual preferred way to consume content, but when none is available the faster playback allows for saving at least a fraction of time.