I think the way to go is a mix of the two. It is covenient for companies to get guaranteed money in advance. As for customer it's way cheaper to start with usage based model. This is because a lot of users are underusing their services.
This at least is the case in hosting industry where overscheduling is a big thing.
So best scenario for customer would be a pay per usage for low usage and subscription for moderate to high usage. At least this is what AWS is doing and I believe this is fair for both bussiness and customer
Here in Lithuania we have like 90% of plastic bottles have a deposit logo on them, pretty much all of the soda, beer, water, milk bottles are recycled. Most of the non recycleable bottles are from outside of EU brands, and those are generally more expensive. Collection points are also automated, where you put them on conveyer kind of belt ant it uses OCR to detect if the bottle can be recycled. Those collection points are attached to a store and you get a credit in associated store which can be used to either buy groceries or jus get your money in cash.
But if your service was down for more than what it takes to downscale to minimum scaling back up is not that big of an issue. It was down anyways. Also 24/7 instances exist for a reason, autoscaling is there to handle spikes, not a normal traffic.
You can have a look at xeon e5-2670 v2 cpus, they're relatively cheap, around $200 and have 8c/16t so in a double cpu configuration you could have 64 cores with only 4 machines.
Why would you really need physical machines for linux and windows, you can always virtualize clients and run dual boot mac/windows or single thinkpad with win/linux dual boot.
If budget is tight used servers are great value, for example del R710 is cheap with plenty of horsepower. Downside being space and sound.
Most of the designed emails have images which will be blocked by the client(thunderbird), which looks really horrible. So I will have to be very interested to actually allow images to be downloaded.
As I understand it he disabled asserts in places which would certainly fail, like doing system stuff, modifying system state and such, but not actual relevant parts.
You can always have multiple VM's with gpu passthrough, so it's almost like dual boot kind of setup, but you can still run other things on the host. It works pretty well for me, only downside being that you're limited to single VM running at the time.
> I am assuming that having RAM and CPU (and other functions such as GPU or other hardware accelerators)
We already have RAM(cache) and GPU(integrated graphics) on the same die. But that doesn't work as a replacement for professional/gaming graphical workloads.
Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.
That's really good case about upstream packaging. Do we really want yet another android story? I trust maintainer which is volunteering it's time to ensure the package complies with distributions guidelines.
With universal packages we would have universal config file paths. So for example: apache2 on debian based systems will store documents on /var/www while something like arch will store them at /srv/httpd. Similar thing happens with a `sites-available` accross distros. Different distributions are doing things differently, which users are expecting and putting upstream developers in charge of that will make a huge mess, because it's more convenient for them to store configuration at a specific location accross every distribution. Yes that makes a pain to write deployment scripts accross difrerent distros, but IMO consistensy is a key to a good distribution.
Another good key point here would be testing, different distributions aim for different things, while debian aims for maximum stability and uses quite dated packages that are known to work. Where there are distributions which are always on the bleeding edge. Will upstream backport security patches for old packages? I really doubt they would like to maintain packages for years to come.
I don't say it would be all bad, there certainly would be great developers which would benefit from universal packaging, but that will not always be the case.
> This should be titled "A Ruby programmer looks at Rust". There are now a very large number of programmers who have zero experience with anything below the level of a scripting language, and have never had to think about memory allocation. To them, Rust is rather intimidating, and this writer is trying to make it simpler.
C++/C doesn't have ownership concept, it may be similar to references but when starting on rust I had to change mindset and constantly fought compiler.
Article itself is interesting because it explains why there is certain syntax, and not a tutorial how you should code in rust.
Yep, that is the reality most of the time. It would be easy if you had a fixed list of features for a project. But they change most of the time throughout the development. You get used to it and start planning accordingly.
As I mostly work on PHP and JS will try to explain how my debugging session usually goes. Most of the bugs are easily reprodusable so for them I just go straight for the file and setup xdebug via PhpStorm. And that almost always gets fixed quickly since I have a good idea what went wrong.
But not all the bugs are easy to solve. The worst kind of bugs are hard/impossible to reproduce. For them my approach is to suspected places where it could occur and add logging, and just wait until it occurs again(sometimes it takes weeks or even months). So I am trying to log how the data flows through the system by isolating the direction to look for.
For example: I'm yet to find cause of the mystery of the MS Word and TinyMCE, where sometimes it will not strip out microsoft's formatting. It only occurs about once a month. I wrote a simple alert script which sends me an email when this happens and I can get to the person in seconds(most of the users are in the same office), and try to reproduce the exact moment when it occured on users computer.
My fix was just show an error asking users to repaste exact same text which then works as expected.
I don't understand why custom solution seems to favourited by them. It's the same as saying your car is bad because it's running on the most popular fuel.
As a web developer working daily on WordPress websites I would argue that it can be as fast as anything else. Because those websites are mostly static which means caching would make it load really fast. Assuming template itself is written well. So it doesn't matter what engine you're using, it's the matter of optimization.
As for WordPress itself, the biggest problem in my oppinion is plugin compatibility. Yes you have thousands of plugins bus most of them doesn't work exactly/cannot be customized to a given requirements and you end up either modifying plugin and then maintaining them. Or just writing simplified version of it yourself. Which makes even more meaintenance overhead.
Also it's not very good for big blogs with more than 100k posts. Because of the database schema used which is both it's strength and weakness at the same time.
I do not agree with your point that you have to pass validation. First of all I don't say that you should leave unclosed tags for browser to figure out. Or doing something crazy to break things.
My point is that we need to use modern tools like html5 while still being backwards compatible with older browser which means breaking some w3c rules.
Another valid case off the top of my head for breaking w3c(haven't tested if it passes validation) would be `<meta>` tags inside body tag. Which is part of the microdata format. Normally you're not supposed to put meta tags outside head but for while using mircrodata you sometimes have to rely on meta tags because your design doesn't allow for required(by microdata) to be shown on the website, so you use meta tag, which doesn't do any harm since it's not rendered for the user.
This at least is the case in hosting industry where overscheduling is a big thing.
So best scenario for customer would be a pay per usage for low usage and subscription for moderate to high usage. At least this is what AWS is doing and I believe this is fair for both bussiness and customer