Submission + - Dave Täht has passed away, aged 59 (libreqos.io)
Some of his work: https://www.bufferbloat.net/pr...
His Wikipedia entry: https://en.wikipedia.org/wiki/...
This company uses machine learning and voice recordings to keep frustrated telemarketers on as long as possible after you merge calls with them: jollyrogertelephone.com
Funny how is number of users is 2^10 + 2^9 - 1. 'Lot of code smell in this article.
This is because release groups are completely, utterly clueless about video. The file size is set ahead of time. Most groups set e.g. "8GB for 1080p movie", "4GB for a 720p movie" etc. in x264. Historically speaking, these pre-selected sizes were designed to fit on different media types, such as CD, single-layer DVD, dual-layer DVD.
Few people use DVDs anymore, but most groups still make files far larger than they need to be.
I rarely download pre-made videos because of this, so haven't downloaded any encoded in h.265, but I suspect they simply chose a smaller pre-set size.
The correct, non-stupid thing to do is to set the quality and let the movie be however large it needs to be, usually under 4GB. This allows more easily encoded video, like CGI films (Toy Story, etc.) to be small while very difficult films (anything with a lot of noise and movement, like war films) are large but don't look terrible.
I always use Staxrip
https://github.com/stax76/stax...
Forgot to add: I was using recent builds (about a month back) of x265.
Whenever a comparison is made, the x265 folks always say that the latest versions are much improved over whatever was used in the comparison. They may be, but they still need some work based on my tests.
I have done my own comparisons of AVC (using x264, single-thread, veryslow preset) and HEVC (using x265, disabling wavefront processing because it slightly reduces quality, veryslow preset). All 1080p video, significant because HEVC is supposed to scale to 4K better than AVC.
My conclusions:
1) x265 takes FAR longer to encode, but we knew that. Understandable.
2) When "low in bits", x265 blurs images rather than making them look blocky. This sometimes looks better but to me often looks worse.
3) x265 seems to force a denoise filter. Video is far easier to encode efficiently when denoised, so I figure this is part of the data savings. It's a bit of a cheat, however, because I can get far smaller file sizes by running a denoise filter myself for x264-encoded video.
I looked closely, for example, at Captain America the Blu-ray. Much of the detail of, e.g. car leather and grass and tree leaves is lost in an x265 encode, even at about the same overall data rate as x265/
x265 supports "--tune grain", roughly analogous to "--tune film" for x264, but it makes the video vastly larger -- often larger than x264's version, and it often looks worse. It does a better job of keeping grain, however.
My experience is very similar to many others' in forums. I had committed to switching my encoding to HEVC, but the results of my tests showed it is not ready for prime time. Some may not mind blurry ("soft" is probably a better word) video, or video that looks like it has been through a denoise filter, but I do.
This is not to say that x265 is junk. I am sure it will mature over time just like x264 had to over time. x264 started out as being not all that much better than divx, the previous generation.
All schemes that involves knowing which direction to point the EM waves ahead of time is structurally incapable of being a WiFi physical layer.
Ruckus and others have had good luck with beam-forming technologies, so having some directionality on the physical layer doesn't necessarily render it incompatible with Wi-Fi (or its various add-ons, AirMax and their ilk). What would render it incompatible with Wi-Fi in my opinion is: it isn't Wi-Fi, your existing Wi-Fi equipment won't work with it (you need a receiver device). It's another physical protocol, they could layer ethernet or anything else over it since they are going to have to implement drivers/integration anyway!
As in Hieronymus, with the "shouldered on the pocketbooks" clause (rolls eyes).
There must be some seriously fine wine flowing somewhere, today.
First of all, congrats on focusing on life outside of computers. Good on you.
Next, to answer your question. How about liquidwar?
I missed "trouble tickets" - we ended up going with RT from Best Practical and linking into it. No need to reinvent the wheel.
I recently helped a small wireless ISP get started, and one of the first things we did was put together a management application. It's grown to be moderately large, but a lot of the functionality required can be constructed from various free sources. My client is chugging away nicely with a Java-based (server-side) system, although it could have been written in any one of a large number of languages - Java was convenient for the available skill-set in the company [never overlook the value of using an environment with which the customer is already skilled!]. The Seam+Hibernate stack provides a very quick development path for most of the CRUD [Create/Read/Update/Delete] functionality that forms the backbone of any data-driven app - but it could just as easily be Access, or (insert favorite ORM here). We found a few commercial systems that could do all of this, but they typically cost more than putting this together ourselves - however, that's partly a function of who you have available.
The key to getting the project off the ground, in use, and genuinely useful was to identify the various areas that are essential - and automate them as building blocks within a framework. You're already used to Access+Excel+manual legwork, so you don't need to start with an amazing UI (although it is a good idea to come up with one that doesn't make the eyes bleed) - identify areas to automate (starting with the biggest pain points) and gradually reduce the pain as you can afford to do so. Also, don't be afraid to use various Free/Open Source packages to help out with sections!
The important chunks for my client (and probably for other ISPs) were:
* Customer database. This acts as the core for a lot of the rest of the system; database (and UI) for customers, their addresses and billing information, account history, etc. Includes tables linking to inventory to indicate what devices they have activated and the details (including billing plan, etc.)
* Inventory system. Lists CPEs, with status, location, ownership info and history. Linked back to the customer database, to make it easy to say "Johnny has this CPE, on that plan". This ended up growing lots of historical options for reporting, but those aren't really essential.
* Activation. This was the biggie for us. When a customer (optionally a new customer) is "activated" with a CPE/plan/etc. (a wizard helps you pick), it adds the appropriate history items and invokes scripts that setup the account in RADIUS and LDAP servers. This is the obvious place to include every step you need - but you can start as simple as "email tells you what to do" while you automate the steps.
* Deactivation. Suspending customers (typically for non-payment), handling CPE returns, etc. You can probably live without this immediately, but it is really nice to have.
* Billing. The first few iterations made CSV files for Quickbooks - that should be fine to get started. The most recent handles credit card payments, etc.
There's also a lot of management niceties, and these were integrated back into the main portal for convenience:
* Cacti for graphing various bits of the network, notably throughput and latency across the network. Very useful for planning.
* Nagios for monitoring the network and paging us when something isn't responding.
As it grows, you'll doubtless end up with a bunch of esoteric scripts also. We even have one that periodically uses an SSH session to log into various access points and records who is online in each sector, what their signal strength is like, and any de-registration events that have occurred. That highlights the biggest pitfall: it is really easy to get excited and try to program in the kitchen sink. If you don't focus on small/modular at the core, you'll end up with a mess - fast. We try to keep the core small, and then have the core UI link into various other tools as we create them.
I currently have a small (3 towers; 3 more going up in the next few months) WiMAX ISP as my primary client. They already had some appropriate frequencies available; if you don't, you either need to find some (schools are a good bet - many have some old licenses lying around that they don't use) - or go with unlicensed frequency bands. That will severely reduce your range/throughput, but has the advantage of being free.
WiMAX is a good fit for the rural model, but there's a fairly hefty setup cost. Most vendors require that you have an ASN-GW at the core of your network, which is a very large initial cost (both in setup time and actual purchase price). The large ones can easily run to a quarter of a million, with smaller models costing a lot less. My client is on NewNet gear (formerly Nokia-Siemens, formerly Motorola - corporate pass-the-parcel), and the setup was pricey - but it performs very well (they have plenty of customers getting 18-20 mbit/s down; upstream on WiMAX isn't so good, expect 3/4 mbit/s on a good day).
You can shave a LOT off the cost by using an open source core to the network (you can't avoid needing RADIUS, DNS, NTP, plus servers for actually running the business), and you could shave more off by going with someone like Alvarion who use a distributed ASN rather than an expensive core (in my experience, performance on Alvarion is decent but not on a par with the NewNet gear). You also need base-stations and antennas per site, but the cost there is quite reasonable in comparison (although "tower monkeys" are expensive to put the stuff up!).
By far the highest long-term cost is backhaul; you need a good connection to each tower (100 mbit/s for full capacity for a 3-sector, max 768 concurrent users). In many areas, dedicated fiber is really expensive - and you end up paying the telco you are trying to supplant. Microwave is a better option - you pay $10-15k up-front (plus FCC license if you need it), but there are no recurring costs. With fiber prices around here, it pays for itself in well under a year. There will also be the cost of your upstream Internet connection; that's incredibly variable by location.
The next cost is CPEs. Our experience has been that the fixed devices sell far better than the mobile devices (mobility isn't so useful when its only within your small network), and the outdoor CPEs need good installation to perform well. Expect to pay $150+ per unit, which can make for a high setup fee.
Finally on the money-side, there's the human cost. You'll want support, enough engineering muscle to monitor/fix your network, and any sales/business side you need. That can be hard to juggle while you get started: mouths to feed while you get enough customers to hit the magical "break even" point. It's a tough phase, and you have to be very careful to keep your spending within reach of this goal. That means you can expect to be working hard for very little for a while - but that's true of most start-up ventures.
It's also worth considering LTE. It's currently an expensive proposition to get into LTE, but you can cover your butt against the eventual inevitable transition. All the major WiMAX players are moving towards a dual-stack mode, allowing you to concurrently run LTE and WiMAX (on different frequencies) on the same gear. Most CPEs scheduled for next year are also dual-stack, so you can deploy WiMAX now and LTE later when you can afford the exorbitant cost of a packet-core (or packet cores come down in price). To do WiMAX well, you want 3-4 10mhz channels; if you can get adjacent frequencies, when you light-up LTE you can start by using one of the 10mhz channels - and gradually phase-out WiMAX adding bands to the LTE side. It isn't free future-proofing, but it's a lot better than knowing you will have to tear out all your gear in a few years.
Another (highly upstream) impediment to combat effectiveness is a change of attitude away from combat-based resolution. O, to have hackers so skilled, from any nation, that yang may cede to yin, at least for a few years, in our lifetimes...
(end lament)
that's a little over 909 kilos.
remember your audience!
oop ack, snort!
"Life, loathe it or ignore it, you can't like it." -- Marvin the paranoid android