Article is WRONG WRONG WRONG. Screen locker: issue chvt onto another X instance, and spawn a thread that goes into a loop reissuing chvt to hold it there until the unlock password is given.
vlock -asn
This has been solved for a long time. Not sure why this is really an issue.
The size of that blacklist (TFA mentions 850,000 numbers, and hundreds of changes a day) may be an issue for a regular phone, particularly the database lookups may be too slow for it to work well.
There are MUCH better ways than what I'm about to suggest, but this is just to get a generic feel for the size of the dataset you're talking about...
US phone numbers easily fit into a 64bit int. 64bit * 850,000 = 54,400,000 bit = 6,800,000 byte = 6.5mb
Even if you just iterated over every item, a phone could search that plenty fast enough (especially if you cache it in memory).
This could also be implemented the same way that the RBL (realtime blacklist) anti-spam lists are managed - DNS. To improve speed when you're not online, sync the data periodically (nightly, weekly, whatever), and let DNS deal with misses by fetching them from the RBL. Lots of ways to do this.
Anyway... the real "problem" or hard part would be in doing PBX-list operations, such as silently answering the call, then doing voice prompts, and interpretting the response from the other end (press 2 if you're a human, etc), and call handling after that point (forwarding them, ringing other lines, voice mail, etc). It all *should* be completely doable on an just about any android phone.... asterisk was out a LONG LONG time ago and handling many calls on single desktop-class machines - versus - on the cell phone, you'll only ever have to handle one call at a time (maybe 2), so there's plenty of power for that. Here's a conversation about it from a couple years ago (plenty of "sure, but I don't know you'd want to do that" naysaying): http://community.spiceworks.co...
And keep in mind that we are blessed with elevator brakes that are actively held open. A self-powered electrical elevator car would have a pretty high constant draw to replicate the braking system, as it would have to pull solenoids against the breaking springs.
Use just a little more creativity. One possibility: Have brakes that are actively held open; hold them open with a quick release mechanism; for the quick release, hold its release via the constant power. If power is cut, it'll trigger the quick release, which will release the stored energy in the springs. It doesn't take much to hold back lots of stored power. Batteries and capacitors could also be employed at various points. Basically, this isn't a problem.
Finally, current elevators don't lift the car. It is counter balanced with a set of stacked weights.
At the proposed scale, 1km, I'm betting all that cable is placing a much higher stress on the system than the minor issue of having to actually lift the car (in addition to its contents).
I'm not claiming it's super easy, or that it'd even be feasible, but it sure seems like having 1km of cable is pretty ridiculous.
I agree.... more than one. If you're going for the "best", then loads and loads of them, and distribute them around the world, and build crazy robots to take care of it all for you, all to protect those sensitive family photos.
Original question should have been, "To all the psychics out there, how much money do you think I want to spend on backups?"
I don't know if "don't want backed up in the cloud" covers all networked technologies, but I personally think many of those are especially good for frequent, stable, and secure backups of small-ish data sets (ex. photos and documents). Backing up your dvd rips would initially take forever that way, but once its up there you can use dedupe/sync style backups to avoid re-uploading them.
Before someone yells about the cloud again, you could just rent some rack space and get a dedicated line to it (after all, there was no price limit mentioned). For that matter, why isn't tape being considered?
You don't survive widespread nuclear war without some pretty drastic measures.
Exactly. My gut response was, "GOOD!" Do you have any idea how many companies do NOT have a disaster recovery plan? No one ever wants to use it, but you'll be MUCH better off with it than without. It could have been a lot worse; Their plan C could have been: * Let's put enough food/water for 10 years in a secure bomb shelter and plan to store the top 0.005% of the population. After they run out of food, who cares.. let's just make sure we can remain fat for a little longer than everyone else. * Launch everything at ourselves. If we can't have it, neither can they.
Cell phone processors might tend to be slow, but they're rather power efficient per operation. Always good in a data center, especially if the single powerful processor gets a lot fewer operations per watt.
So what's the answer? Can networking a bunch of these low power cell phone cpu's together (along with their supporting components) end up producing more (useful) operations per watt than a new and beefy cpu? I bet the answer is no, and that was (part of) itzly's point.
AFAIK, that's not a thing. You don't open source an API, as an API is a documented interface, not source; Similarly, see java's API battles with Google - reimplementing someone elses API is fair play. This doesn't make it "open source" though. Regardless, where is the WhatsApp API documented? I couldn't find any mention of it on their site. The closest I got was: https://www.whatsapp.com/faq/e... That's 2 ways for an iPhone APP to integrate with WhatsApp, which is not a full API, but just a way for an app to send messages by triggering WhatsApp.
On the other hand whatsapp plus is and was never available in the play store or any other official store.
I don't know how accurate that statement is. I just looked, and there are things like "Install WhatsApp Plus+" app on the google play store, and (possibly not exactly the same thing) there's WhatsApp Pro and WhatsApp_World on the amazon store.
About the name infrigment I agree with most of you but enhancing an app that is licensed under the GNU or GPLI license with open source Api's is free.
WhatsApp is not available under the GPL. In addition, when forking a GPL'd project, you must still change the name. See netscape/mozilla/firefox, or openoffice/libreoffice/etc. There's loads of examples, but you don't steal a name because that's similar to saying you wrote the thing (or that they wrote your thing). You can use a related name, but it should be clearly different.
From a developer's point of view it's called improvement. Since they only ask donations just to go further with the development of it.
Ok, so I tried to find WhatsApp Plus+, assuming the source would be available since he's just making improvements and such. Where is it!?! There's loads of different sites with downloads for it, and they all look pretty shady and have very short FAQ pages (like 3-4 entries with nothing of real value). Where is its real home page? The version on uptodown.com seems to be the top page for it, but uptodown.com is just another play store and even has loads of random downloads for windows, mac, linux, android, etc... that's not the developers page.
Give financial services... to people who have NO Money. Why didn't we think of this earlier?
Over 150million sims out there (that's cell phones) and 173million people... there's money to be dealt with.
I was surprised at teh number of people... just one of those facts I wasn't aware of. Nigeria: 173.6 million people per 923,768 sq km = 187.9 people per sq km. New York State (for comparison): 19.7 million people per 141,300 sq km = 139.4 people per sq km.
Less than 10% of the people have bank cards, but over 86% have a cell phone, and there's almost 9x's as many people as New York state. That's a big market.
However, these are users. They did not MAKE Whatsapp Plus.
The users are being banned, rather than the "Whatsapp Plus" distribution channels and such. IMO, this reminds me of AdBlock and AdBlockPlus and the other very similarly named programs... there's a real problem there.
Some of them, perhaps most of them are unaware that they are not affiliated.
...and this seems to be one of the most direct ways to let those users know. If the users aren't using teh official Whatsapp app, then they can't communicate with them through it. And it appears they can't get the clone off of the stores... not that it would help (wouldn't let anyone know).
Personally, I think the API and Protocol should be open, and others should be free to make compatible apps. However, the Whatsapp name should not be used. This is VERY clearly an unauthorized and inappropriate use of the name. If Whatapp Plus was renamed.... well, I think we could get into some more interesting discussions then.
``We even instruct children to 'stop, look, and listen'.''
So the govt. puts out PSAs that urge people to `stop, look, and look again' when crossing the street.
... or a PSA to 'stop, look, and make a shit ton of noise so the cars and bikes can hear you'.
Honestly though, this line of argument seems stupid to me. We're already well past the point of having many vehicles that are nearly silent, especially in relation to other ambient noise in cities. This has been the case for a long time.
This also reminds me of the myth from the motorcycle world that "Loud pipes save lives". For one, that's a myth. For two, the intent of that is that other road-colleagues would notice the rider, rather than a concern over pedestrians.
That's part of what I can here to say/read. They're citing lack of a blackberry version of iMessage as an example, and yet where are the iPhone, Android, Symbian, etc versions of BBM!?!?!
Regardless, their argument is retarded. "...if we truly want a free, open and non-discriminatory internet", then we actually have to allow any and all apps to use it in any way they want, rather than forcing them to make their thing available everywhere (and how far does "everywhere" even go!?!? My PC? Mac, Windows, Linux, BSD, Solaris, my ancient HP-UX box, the obscure vm's I run, the roku, game systems (ps3, xbox), what about older game systems (nintendo 64, DS, etc)). There's so much wrong about BB's statement that it makes my head hurt trying to figure out which is most wrong.
I agree on the obviousness. If possible, I think they should have something that can work with a variety of existing glasses, and multiple styles of their own (like lots and lots), including completely covert ones. With all the folks threatening to beat down on anyone with a camera on their face, it makes more sense to give up on making it obvious (as google glass 1.0 was), and definitely don't go adding red recording lights and stuff.
As for utility, the single biggest hope/wish I have is for some tech that'll do facial recognition and remind me who the person is. Maybe some way to get some additional info too (last facebook/twitter/email exchanged with them, family member names, age, birtthdate, upcoming calendar events, etc).
Another option I wouldn't mind seeing is a non-glass glass. Have a camera and audio (ex. earbud and mic). Control it via voice or using an app on your phone. Facial recognition, for example, could still work just fine that way. Maybe dedicate a hardware button the on the phone or a remote to enabling the currently running feature (ex. facial recognition trigger). It could work like a portable amazon echo with an added camera (I personally think the camera feed is invaluable, but there could be cheaper models without the cam accessory... they'd just be a bluetooth ear piece with a helper app at that point).
Does that really address the problem? People don't like the idea that Google Glass can be used to record them covertly, so your solution is to make it more covert? I haven't seen any of them yelling about all the other camholes out there (anyone using a camera to record anything, especially those with pinhole cams, or actual secret cameras). If you want glasses that'll record stuff fairly discreetly, you can even get this toy (ages 8+) for $25: http://www.amazon.com/Spy-Gear... That looks like fairly normal pair of sunglasses, and probably takes a better pic than google glass. There's TONS of similar things out there that are readily avaialble, and no ones really yelling about those.
you can turn off the fake shutter sound now and that man in the corner staring down at his cellphone probably isn't trying to take a perv shot of you (probably).
The difference is when people are using their phones to do things other than taking photos or videos they aren't pointing the camera up at you. Sure you can surreptitiously snap a few shots as you swing the camera around and hope you get one framed ok and not blurry but the difference between that and Google Glass is that Google Glass is like you're always pointing the camera up at people.
Ugh. Wrong. 1. If someone wearing google glass is recording you, he'll have to be facing you. It's pretty obvious when someone is staring at me, just as that'll be pretty obvious. It's even more obvious than when someone is just holding their phone in their hand by their side in a horizontal fist clutch type of way... which looks very very natural, and also can aim to record anyone around them from a comfortable and unobtrusive way.
2. If someone wants to record people secretly, there are FAR FAR better ways to do it, and they're even cheaper. pinhole cameras are dirt cheap by comparison, and you'll never see them. If you want the same "look where I record" feature, just put the camera in a hat.
3. You're already being recorded in most places. I'm completely open to discussing modifications to laws and standards regarding recordings in general, but they're already everywhere, and the recordings are already perfectly legal for private use in almost all cases/situations (ex. security cameras, dash cams).
I'm pretty sure there actually are a bunch of people that honestly have the whole "these glassholes shouldn't be allowed to exist in public-semi-private-places" mindsets, but it seems so illogical to me that I find it hard to believe that many of these aren't just shills and fakes. Why can't we just talk about the cool futuristic stuff these things cool do? Wearable computing is basically here, and there's all this awful noise and name-calling, on slashdot, that's drowning out all the useful conversation.
Systemd is actually *really* easy to get rid of, you just have to be willing to do without Gnome and other packages that depend upon it.
If you aren't willing to make that choice, then you have chosen to run with it.
Statements like this are one of the many reasons people get pissed about systemd. I can't tell if this is just a really good troll, or if you seriously believe that and are ok with it, but I suspect that latter just because of apparent mindset of pro-systemd folks. So, assuming the latter...
You're saying systemd is easy to get rid of, if you get rid of all the things that now depend on it, and those that will in the future. Logind, for example, which means Gnome, which means other gnome stuff, and that's just one branch of the tree (though probably the most prominent at this time). That's just ridiculous for a desktop app or a display manager (gdm/xdm/kdm/etc) to depend on a specific init system (it doesn't directly, but GDM depends on logind, which depends on systemd). How about an example...
What if KDE started depending on something similar but different than logind, and it depended on a different init system. If that happened, I couldn't have one user using gnome and another using KDE using fast user switching on the desktop. That'd require a bunch of compatibility stuff to be in place... which is actually something those two groups (and others) have been working hard at for years (ex. shared "start" menus, session management, audio multiplexing (arts/esd/pulse), etc).
Regaring gnome+logind+system, I found this to be a good read: https://blogs.gnome.org/ovitte... It sort of argues that gnome doesn't need systemd. However, it acknowledges that: * GNOME 3.8 doesn't directly require logind *... but GDM assumes (requires) an init system that will also clean up any process it started. Basically, it needs a feature that is more-or-less unique to systemd. * If logind is required/included, GNOME did NOT intend for this to mean systemd was also required. However, their assumption that logind was independent from systemd changed since systemd v205 due to cgroups kernel change. * similar stuff continues regarding session management, wayland, etc etc
Those are, IMO, huge red flags. A very large project starts making many parts dependent on some (currently) independent project (logind). Then logind/systemd inject some dependencies, and now gnomes intent is screwed - they're essentially depending on a specific init system now. How is that a good thing?
FWIW, I'm NOT saying that: * gnome shouldn't be free to develop as it wishes * systemd shouldn't be allowed to do what it's doing * users shouldn't be free to use this stuff * distros shouldn't be free to choose these things... but why is it so difficult for so many people to understand why this pisses off many many people? Seems pretty obvious for many reasons.
Personally, I think many of the distros have failed us with this integration. It shouldn't have been allowed to be the default until, at the minimum, compatibility layers were available (ex. uselessd). Maybe have some forks that made it the fully integrated default, but debian... ouch. It's parts are actually more of a problem than systemd itself... there should be a logind alternative, or it should be capable of running without systemd (same goes for all the other "modular" parts). I'm not saying the devs should be forced to do this; I'm saying distros and users shouldn't accept it as the default until that flexibility is in place.
Sorry that this has almost nothing to do with *BSD, except that it lacks systemd.
I'm pretty confused about why Dish would be the one doing this though. Adding dish subscribers doesn't cost them anything really (past licensing fees)... why not just lower the cost of that? I know its quite different but, if anything, the steaming service is more flexible and will cost them more for the delivery. The licensing rules/laws/agreements must be super fucked up.
Building and launching a satellite is a billion-dollar capital cost, that has to be amortized over the life of the satellite. For the same money over the next few years, they can gradually roll out a streaming service without having to put up all that capital in one chunk. Plus, if they stop using satellites, they can knock out the people pirating their signal.
Your argument works against itself. They already launched the satellites. That "billiion-dollar capital cost" is already sunk. There is no "for the same money". The "for the same money" would only be relevant if we were talking about some other company that hadn't launched all those satellites and already has a large number fo people paying lots per month for it. Any additional money they can squeeze out of it by getting new disk subscribers is, essentially, free money.
The only possible reason they have to do this is because "on the internet" is a loophole through their licensing agreements, which lets them make such a small bundle (which, unfortunately, is/still/ a stupid bundle).
How the flying fuck is that any different from DST?
You are either scheduling your jobs by timestamp/UTC, or by something affected by a DST change.
Your example applies exactly the same to DST change events... just change the duration it took Job A to complete.
Parent is essentially saying (though he may not be aware precisely), "let's use TAI instead of UTC, and use tzdata (or similar) to account for the leap second".
Going from unixtime back to UTC during the leap second is like trying to go from DST back to UTC during "fall back". FWIW, it also does the opposite if a leap second is a removal (day ending in UTC 23:59:58.9999-)... unix time skips over that second entirely.
Do to all that, many of the standard time utilities don't actually parse 23:59:60. I'm sure there are many that do (and do not use unixtime as the underlying counter), but many of them don't. Cheap example: $ TZ=UTC date -d "1998-12-31 23:59:60" date: invalid date `1998-12-31 23:59:60'
But I have longed for a good portable player I could use with flac which is what I have my music ripped to on my living room BIG system (tube amps, klipschorn speakers, etc).
Android has supported FLAC since 3.1 : http://developer.android.com/g... So nearly any android phone or media player will do it. Samsung Galaxy Player was a decent iPod-touch-like device.
In addition, the Sandisk players (I don't know if it's all of them, but at least the Sansa Clip) support Flac, and they can be found very cheap.
Archos was one of the first with a really polished player that also supported Flac, and kept making a HDD based one for quite a long time. Sadly, I think Archos backed out of the media player arena (probably because people kept saying "I have longed for XYZ", and then not buying it when they made it).
This Sony thing has a little more than normal onboard memory. Otherwise, it's nothing special AFAICT.
I'm pretty sure he meant that the customer isn't paying one lump sum to one company for both the delivery of goods and for the goods themselves.
One of the arguments that often comes up over cable prices is that they have to pay to put all the cables in place and maintain them. For satellite, they had to pay boatloads to put a satellite in orbit. This makes somewhat of a separation between the two.
I'm pretty confused about why Dish would be the one doing this though. Adding dish subscribers doesn't cost them anything really (past licensing fees)... why not just lower the cost of that? I know its quite different but, if anything, the steaming service is more flexible and will cost them more for the delivery. The licensing rules/laws/agreements must be super fucked up.
SSH connections take For. Eh. Ver. relatively speaking:
gethotbyaddr + getpeername + gethostbyname
Try configuring your DNS correctly; the reason it's fast with Google as a remote host is that their DNS is correctly configured.
No, the reason HTTPS is fast (with respect to a comparison to SSH + gethostbyaddr/etc) is because the webserver isn't doing ANY** reverse DNS. The config change needed would be putting "UseDNS no" in sshd_config.
There are other slow downs as well. For example, HTTPS normally has nothing to do with authentication, but SSH almost always makes a bunch of attempts for various auth types (GSSAPI, host based, public key (DSA, RSA, ECDSA), keyboard interactive, password). There's a fair bit more back-end-forth for ssh. Just do "ssh -vvv exit | grep -i '\(sent\|receive\)'", and compare that to "openssl s_client -connect www.google.com:443".
** in almost all cases this is true, and especially if performance is valued. The most common time it is used is for log resolution (usually done in post-processing) and IP allows by DNS subdomains (which is frowned upon for multiple reasons).
Parent is one side of the "why not". The other is, "why *would* we use ssh for everything?".
The summary (I'm not going to bother reading the article) makes it sound like they want to use ssh in place of HTTPS. That's stupid. We have secure protocols for many things that each fit correctly (ipsec, https, sftp, ssh, various-vpns (ssl/tls/etc), s/mime, pgp/gpg, etc).
The summary says, "SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords." WTF? I'm guessing they're referring to public key authentication, which HTTPS has (and I'd assume would work in HTTP/2 as well). You can use client based ssl certs for auth. It's a PITA, just as it would be to use ssh keys - the client side management of said info would need to be solved in a very dumbed down and friendly way.
Some other things it has (and I assume they imply that HTTPS does not have?):
* Binary protocol. ssh just sets up a secure channel. It's not a binary protocol for all the other bits (like shell commands), which are all encrypted plain text. Ditto to HTTPS/SSL/TLS... where's the difference here? HTTP/2 proposal would have a binary protocol, though I don't really see much benefit to that.
* mandatory encryption. ssh = nope. You can, but you could also allow the null cipher. IE. it has to be configured for that way of operations. HTTPS/SSL/TLS - enable HSTS header and do a permenant redirect on port 80 to 443, done.
* multiplexing. I'll admit this may be a benefit, but I see little benefit over simply using multiple connections with keepalive. Prove there's an actual performance benefit and then we'll talk. Meanwhile, as parent mentioned, ssh connection establishment is VERY SLOW in comparison to HTTPS.
Please note, I'm not saying HTTP/2 is bad, nor that the features in HTTP/2 fall to the same points above. I'm saying those points do not apply, apply poorly, or already have a better solution in HTTPS as compared to SSH.
Not only is the punishment unjustly targeted, but it harms exactly the _wrong_ people.
Agreed. See Cuba. How the hell are we making this same mistake so soon after (finally) starting to fix that one?
FWIW, I'm no NK fan. I get that dealing with them is a giant political mess, but that hasn't changed one iota. We should have ripped the bandaid off long ago. Cut it in half (Jonchon to Wonsan) and give China the north and SK the bottom (creating a new land based trade route between SK and mainland China; and getting China port access on the Sea of Japan). I kinda miss the days when the outcome of a war was new territory; now it's like we're playing poker without any chips - worst game ever.
Traveling 3LY instead of 16LY means only having to reach 1/5 the speed to arrive in a "reasonable" time. That's a big help. It might be the difference between doable but hard and hopeless.
Meanwhile, if we wait for that 3LY window, we'll be waiting 250,000 - 470,000 years (15,000 - 29,000 x's as long as it would take to travel at light speed right now). Let's consider your 1/5th figure... if traveling at 1/5th the speed of light: * leaving now, it'd take ~80 years * leaving when we're 3LY away, the travel would take only 15 years, but you have to add on the 250,000 - 470,000 year wait. No society we know of has lasted that long.
If someone happens to swing by close while we're at a high point in society, then go for it, but it's not something I'd try to plan on doing (disclaimer: i have trouble planning what I'll be doing a week or two from now; I still think I'm qualified enough to say we can't plan on the scale of hundreds of thousands of years)
... but no problems with AMD/ATI as of several years now (2D only)......and that is important to me because there are just two main vendors in the graphics category.
Slowly it's becoming three, with Intel's HD Graphics and Iris hardware....
[bold part by me] If we're talking about 2d only, then it's definitely at least 3 vendors, and there are some others that are perfectly fine in that realm.
To the AC GP, It's also not at all fair to say you haven't seen any problems for a few years while qualifying that you've only used 2d. The whole damn article is about 3d performance, and that's the part of the driver that is the most complex and has the most proprietary bits. I haven't had any problems with my AMD/ATI cards on my headless servers either, but that's hardly relevant.
People talking about the wonders of open source should do an experiment where they personally actually fix some little thing in one open source project.
Trolls that keep posting crap like this should eat their own dogfood - try it yourself before extolling the horrors, and try it with both the closed source product and the competing open source one. I've done this. IME, you're full of shit.
It's also worth noting that the bug was reported over 90 days ago. "proper fix takes ages"... results will vary wildly depending on the product, the bug report, and the bug, but the majority would be addressable well within that time frame. In most cases, you won't have to do anything as the maintainers will handle it, just like (a good) closed source maintainer would.
Slashdot Mirror
Article is WRONG WRONG WRONG. Screen locker: issue chvt onto another X instance, and spawn a thread that goes into a loop reissuing chvt to hold it there until the unlock password is given.
vlock -asn
This has been solved for a long time. Not sure why this is really an issue.
The size of that blacklist (TFA mentions 850,000 numbers, and hundreds of changes a day) may be an issue for a regular phone, particularly the database lookups may be too slow for it to work well.
There are MUCH better ways than what I'm about to suggest, but this is just to get a generic feel for the size of the dataset you're talking about...
US phone numbers easily fit into a 64bit int.
64bit * 850,000 = 54,400,000 bit = 6,800,000 byte = 6.5mb
Even if you just iterated over every item, a phone could search that plenty fast enough (especially if you cache it in memory).
This could also be implemented the same way that the RBL (realtime blacklist) anti-spam lists are managed - DNS. To improve speed when you're not online, sync the data periodically (nightly, weekly, whatever), and let DNS deal with misses by fetching them from the RBL. Lots of ways to do this.
Anyway... the real "problem" or hard part would be in doing PBX-list operations, such as silently answering the call, then doing voice prompts, and interpretting the response from the other end (press 2 if you're a human, etc), and call handling after that point (forwarding them, ringing other lines, voice mail, etc). It all *should* be completely doable on an just about any android phone.... asterisk was out a LONG LONG time ago and handling many calls on single desktop-class machines - versus - on the cell phone, you'll only ever have to handle one call at a time (maybe 2), so there's plenty of power for that. Here's a conversation about it from a couple years ago (plenty of "sure, but I don't know you'd want to do that" naysaying): http://community.spiceworks.co...
And keep in mind that we are blessed with elevator brakes that are actively held open. A self-powered electrical elevator car would have a pretty high constant draw to replicate the braking system, as it would have to pull solenoids against the breaking springs.
Use just a little more creativity. One possibility: Have brakes that are actively held open; hold them open with a quick release mechanism; for the quick release, hold its release via the constant power. If power is cut, it'll trigger the quick release, which will release the stored energy in the springs. It doesn't take much to hold back lots of stored power. Batteries and capacitors could also be employed at various points. Basically, this isn't a problem.
Finally, current elevators don't lift the car. It is counter balanced with a set of stacked weights.
At the proposed scale, 1km, I'm betting all that cable is placing a much higher stress on the system than the minor issue of having to actually lift the car (in addition to its contents).
I'm not claiming it's super easy, or that it'd even be feasible, but it sure seems like having 1km of cable is pretty ridiculous.
I agree.... more than one. If you're going for the "best", then loads and loads of them, and distribute them around the world, and build crazy robots to take care of it all for you, all to protect those sensitive family photos.
Original question should have been, "To all the psychics out there, how much money do you think I want to spend on backups?"
I don't know if "don't want backed up in the cloud" covers all networked technologies, but I personally think many of those are especially good for frequent, stable, and secure backups of small-ish data sets (ex. photos and documents). Backing up your dvd rips would initially take forever that way, but once its up there you can use dedupe/sync style backups to avoid re-uploading them.
Before someone yells about the cloud again, you could just rent some rack space and get a dedicated line to it (after all, there was no price limit mentioned). For that matter, why isn't tape being considered?
You don't survive widespread nuclear war without some pretty drastic measures.
Exactly. My gut response was, "GOOD!" Do you have any idea how many companies do NOT have a disaster recovery plan? No one ever wants to use it, but you'll be MUCH better off with it than without.
It could have been a lot worse; Their plan C could have been:
* Let's put enough food/water for 10 years in a secure bomb shelter and plan to store the top 0.005% of the population. After they run out of food, who cares.. let's just make sure we can remain fat for a little longer than everyone else.
* Launch everything at ourselves. If we can't have it, neither can they.
Cell phone processors might tend to be slow, but they're rather power efficient per operation. Always good in a data center, especially if the single powerful processor gets a lot fewer operations per watt.
So what's the answer? Can networking a bunch of these low power cell phone cpu's together (along with their supporting components) end up producing more (useful) operations per watt than a new and beefy cpu? I bet the answer is no, and that was (part of) itzly's point.
The API's are open source so enhancing is easy.
AFAIK, that's not a thing. You don't open source an API, as an API is a documented interface, not source; Similarly, see java's API battles with Google - reimplementing someone elses API is fair play. This doesn't make it "open source" though.
Regardless, where is the WhatsApp API documented? I couldn't find any mention of it on their site. The closest I got was: https://www.whatsapp.com/faq/e...
That's 2 ways for an iPhone APP to integrate with WhatsApp, which is not a full API, but just a way for an app to send messages by triggering WhatsApp.
On the other hand whatsapp plus is and was never available in the play store or any other official store.
I don't know how accurate that statement is. I just looked, and there are things like "Install WhatsApp Plus+" app on the google play store, and (possibly not exactly the same thing) there's WhatsApp Pro and WhatsApp_World on the amazon store.
About the name infrigment I agree with most of you but enhancing an app that is licensed under the GNU or GPLI license with open source Api's is free.
WhatsApp is not available under the GPL.
In addition, when forking a GPL'd project, you must still change the name. See netscape/mozilla/firefox, or openoffice/libreoffice/etc. There's loads of examples, but you don't steal a name because that's similar to saying you wrote the thing (or that they wrote your thing). You can use a related name, but it should be clearly different.
From a developer's point of view it's called improvement. Since they only ask donations just to go further with the development of it.
Ok, so I tried to find WhatsApp Plus+, assuming the source would be available since he's just making improvements and such. Where is it!?! There's loads of different sites with downloads for it, and they all look pretty shady and have very short FAQ pages (like 3-4 entries with nothing of real value). Where is its real home page? The version on uptodown.com seems to be the top page for it, but uptodown.com is just another play store and even has loads of random downloads for windows, mac, linux, android, etc... that's not the developers page.
Give financial services ... to people who have NO Money.
Why didn't we think of this earlier?
Over 150million sims out there (that's cell phones) and 173million people... there's money to be dealt with.
I was surprised at teh number of people... just one of those facts I wasn't aware of.
Nigeria: 173.6 million people per 923,768 sq km = 187.9 people per sq km.
New York State (for comparison): 19.7 million people per 141,300 sq km = 139.4 people per sq km.
Less than 10% of the people have bank cards, but over 86% have a cell phone, and there's almost 9x's as many people as New York state. That's a big market.
However, these are users. They did not MAKE Whatsapp Plus.
The users are being banned, rather than the "Whatsapp Plus" distribution channels and such. IMO, this reminds me of AdBlock and AdBlockPlus and the other very similarly named programs... there's a real problem there.
Some of them, perhaps most of them are unaware that they are not affiliated.
...and this seems to be one of the most direct ways to let those users know. If the users aren't using teh official Whatsapp app, then they can't communicate with them through it. And it appears they can't get the clone off of the stores... not that it would help (wouldn't let anyone know).
Personally, I think the API and Protocol should be open, and others should be free to make compatible apps. However, the Whatsapp name should not be used. This is VERY clearly an unauthorized and inappropriate use of the name. If Whatapp Plus was renamed.... well, I think we could get into some more interesting discussions then.
So the govt. puts out PSAs that urge people to `stop, look, and look again' when crossing the street.
... or a PSA to 'stop, look, and make a shit ton of noise so the cars and bikes can hear you'.
Honestly though, this line of argument seems stupid to me. We're already well past the point of having many vehicles that are nearly silent, especially in relation to other ambient noise in cities. This has been the case for a long time.
This also reminds me of the myth from the motorcycle world that "Loud pipes save lives". For one, that's a myth. For two, the intent of that is that other road-colleagues would notice the rider, rather than a concern over pedestrians.
That's part of what I can here to say/read.
They're citing lack of a blackberry version of iMessage as an example, and yet where are the iPhone, Android, Symbian, etc versions of BBM!?!?!
Regardless, their argument is retarded.
"...if we truly want a free, open and non-discriminatory internet", then we actually have to allow any and all apps to use it in any way they want, rather than forcing them to make their thing available everywhere (and how far does "everywhere" even go!?!? My PC? Mac, Windows, Linux, BSD, Solaris, my ancient HP-UX box, the obscure vm's I run, the roku, game systems (ps3, xbox), what about older game systems (nintendo 64, DS, etc)). There's so much wrong about BB's statement that it makes my head hurt trying to figure out which is most wrong.
I agree on the obviousness. If possible, I think they should have something that can work with a variety of existing glasses, and multiple styles of their own (like lots and lots), including completely covert ones. With all the folks threatening to beat down on anyone with a camera on their face, it makes more sense to give up on making it obvious (as google glass 1.0 was), and definitely don't go adding red recording lights and stuff.
As for utility, the single biggest hope/wish I have is for some tech that'll do facial recognition and remind me who the person is. Maybe some way to get some additional info too (last facebook/twitter/email exchanged with them, family member names, age, birtthdate, upcoming calendar events, etc).
Another option I wouldn't mind seeing is a non-glass glass. Have a camera and audio (ex. earbud and mic). Control it via voice or using an app on your phone. Facial recognition, for example, could still work just fine that way. Maybe dedicate a hardware button the on the phone or a remote to enabling the currently running feature (ex. facial recognition trigger). It could work like a portable amazon echo with an added camera (I personally think the camera feed is invaluable, but there could be cheaper models without the cam accessory... they'd just be a bluetooth ear piece with a helper app at that point).
Does that really address the problem? People don't like the idea that Google Glass can be used to record them covertly, so your solution is to make it more covert?
I haven't seen any of them yelling about all the other camholes out there (anyone using a camera to record anything, especially those with pinhole cams, or actual secret cameras). If you want glasses that'll record stuff fairly discreetly, you can even get this toy (ages 8+) for $25: http://www.amazon.com/Spy-Gear...
That looks like fairly normal pair of sunglasses, and probably takes a better pic than google glass. There's TONS of similar things out there that are readily avaialble, and no ones really yelling about those.
you can turn off the fake shutter sound now and that man in the corner staring down at his cellphone probably isn't trying to take a perv shot of you (probably).
The difference is when people are using their phones to do things other than taking photos or videos they aren't pointing the camera up at you. Sure you can surreptitiously snap a few shots as you swing the camera around and hope you get one framed ok and not blurry but the difference between that and Google Glass is that Google Glass is like you're always pointing the camera up at people.
Ugh. Wrong.
1. If someone wearing google glass is recording you, he'll have to be facing you. It's pretty obvious when someone is staring at me, just as that'll be pretty obvious. It's even more obvious than when someone is just holding their phone in their hand by their side in a horizontal fist clutch type of way... which looks very very natural, and also can aim to record anyone around them from a comfortable and unobtrusive way.
2. If someone wants to record people secretly, there are FAR FAR better ways to do it, and they're even cheaper. pinhole cameras are dirt cheap by comparison, and you'll never see them. If you want the same "look where I record" feature, just put the camera in a hat.
3. You're already being recorded in most places. I'm completely open to discussing modifications to laws and standards regarding recordings in general, but they're already everywhere, and the recordings are already perfectly legal for private use in almost all cases/situations (ex. security cameras, dash cams).
I'm pretty sure there actually are a bunch of people that honestly have the whole "these glassholes shouldn't be allowed to exist in public-semi-private-places" mindsets, but it seems so illogical to me that I find it hard to believe that many of these aren't just shills and fakes. Why can't we just talk about the cool futuristic stuff these things cool do? Wearable computing is basically here, and there's all this awful noise and name-calling, on slashdot, that's drowning out all the useful conversation.
Systemd is actually *really* easy to get rid of, you just have to be willing to do without Gnome and other packages that depend upon it.
If you aren't willing to make that choice, then you have chosen to run with it.
Statements like this are one of the many reasons people get pissed about systemd. I can't tell if this is just a really good troll, or if you seriously believe that and are ok with it, but I suspect that latter just because of apparent mindset of pro-systemd folks. So, assuming the latter...
You're saying systemd is easy to get rid of, if you get rid of all the things that now depend on it, and those that will in the future. Logind, for example, which means Gnome, which means other gnome stuff, and that's just one branch of the tree (though probably the most prominent at this time). That's just ridiculous for a desktop app or a display manager (gdm/xdm/kdm/etc) to depend on a specific init system (it doesn't directly, but GDM depends on logind, which depends on systemd). How about an example...
What if KDE started depending on something similar but different than logind, and it depended on a different init system. If that happened, I couldn't have one user using gnome and another using KDE using fast user switching on the desktop. That'd require a bunch of compatibility stuff to be in place... which is actually something those two groups (and others) have been working hard at for years (ex. shared "start" menus, session management, audio multiplexing (arts/esd/pulse), etc).
Regaring gnome+logind+system, I found this to be a good read: https://blogs.gnome.org/ovitte... ... but GDM assumes (requires) an init system that will also clean up any process it started. Basically, it needs a feature that is more-or-less unique to systemd.
It sort of argues that gnome doesn't need systemd. However, it acknowledges that:
* GNOME 3.8 doesn't directly require logind
*
* If logind is required/included, GNOME did NOT intend for this to mean systemd was also required. However, their assumption that logind was independent from systemd changed since systemd v205 due to cgroups kernel change.
* similar stuff continues regarding session management, wayland, etc etc
Those are, IMO, huge red flags. A very large project starts making many parts dependent on some (currently) independent project (logind). Then logind/systemd inject some dependencies, and now gnomes intent is screwed - they're essentially depending on a specific init system now. How is that a good thing?
FWIW, I'm NOT saying that: ... but why is it so difficult for so many people to understand why this pisses off many many people? Seems pretty obvious for many reasons.
* gnome shouldn't be free to develop as it wishes
* systemd shouldn't be allowed to do what it's doing
* users shouldn't be free to use this stuff
* distros shouldn't be free to choose these things
Personally, I think many of the distros have failed us with this integration. It shouldn't have been allowed to be the default until, at the minimum, compatibility layers were available (ex. uselessd). Maybe have some forks that made it the fully integrated default, but debian... ouch. It's parts are actually more of a problem than systemd itself... there should be a logind alternative, or it should be capable of running without systemd (same goes for all the other "modular" parts). I'm not saying the devs should be forced to do this; I'm saying distros and users shouldn't accept it as the default until that flexibility is in place.
Sorry that this has almost nothing to do with *BSD, except that it lacks systemd.
...
I'm pretty confused about why Dish would be the one doing this though. Adding dish subscribers doesn't cost them anything really (past licensing fees)... why not just lower the cost of that? I know its quite different but, if anything, the steaming service is more flexible and will cost them more for the delivery. The licensing rules/laws/agreements must be super fucked up.
Building and launching a satellite is a billion-dollar capital cost, that has to be amortized over the life of the satellite. For the same money over the next few years, they can gradually roll out a streaming service without having to put up all that capital in one chunk. Plus, if they stop using satellites, they can knock out the people pirating their signal.
Your argument works against itself. They already launched the satellites. That "billiion-dollar capital cost" is already sunk. There is no "for the same money". The "for the same money" would only be relevant if we were talking about some other company that hadn't launched all those satellites and already has a large number fo people paying lots per month for it. Any additional money they can squeeze out of it by getting new disk subscribers is, essentially, free money.
The only possible reason they have to do this is because "on the internet" is a loophole through their licensing agreements, which lets them make such a small bundle (which, unfortunately, is /still/ a stupid bundle).
How the flying fuck is that any different from DST?
You are either scheduling your jobs by timestamp/UTC, or by something affected by a DST change.
Your example applies exactly the same to DST change events... just change the duration it took Job A to complete.
Parent is essentially saying (though he may not be aware precisely), "let's use TAI instead of UTC, and use tzdata (or similar) to account for the leap second".
That's actually somewhat like what strict unix time does: http://en.wikipedia.org/wiki/U...
actual UTC, gmtime of unixtime, unix timestamp
1998-12-31T23:59:59.00, 1998-12-31T23:59:59.00, 915 148 799.00
1998-12-31T23:59:60.00, 1999-01-01T00:00:00.00, 915 148 800.00
1999-01-01T00:00:00.00, 1999-01-01T00:00:00.00, 915 148 800.00
1999-01-01T00:00:01.00, 1999-01-01T00:00:01.00, 915 148 801.00
Going from unixtime back to UTC during the leap second is like trying to go from DST back to UTC during "fall back".
FWIW, it also does the opposite if a leap second is a removal (day ending in UTC 23:59:58.9999-)... unix time skips over that second entirely.
Do to all that, many of the standard time utilities don't actually parse 23:59:60. I'm sure there are many that do (and do not use unixtime as the underlying counter), but many of them don't. Cheap example:
$ TZ=UTC date -d "1998-12-31 23:59:60"
date: invalid date `1998-12-31 23:59:60'
But I have longed for a good portable player I could use with flac which is what I have my music ripped to on my living room BIG system (tube amps, klipschorn speakers, etc).
Android has supported FLAC since 3.1 : http://developer.android.com/g...
So nearly any android phone or media player will do it. Samsung Galaxy Player was a decent iPod-touch-like device.
In addition, the Sandisk players (I don't know if it's all of them, but at least the Sansa Clip) support Flac, and they can be found very cheap.
Archos was one of the first with a really polished player that also supported Flac, and kept making a HDD based one for quite a long time. Sadly, I think Archos backed out of the media player arena (probably because people kept saying "I have longed for XYZ", and then not buying it when they made it).
This Sony thing has a little more than normal onboard memory. Otherwise, it's nothing special AFAICT.
I'm pretty sure he meant that the customer isn't paying one lump sum to one company for both the delivery of goods and for the goods themselves.
One of the arguments that often comes up over cable prices is that they have to pay to put all the cables in place and maintain them. For satellite, they had to pay boatloads to put a satellite in orbit. This makes somewhat of a separation between the two.
I'm pretty confused about why Dish would be the one doing this though. Adding dish subscribers doesn't cost them anything really (past licensing fees)... why not just lower the cost of that? I know its quite different but, if anything, the steaming service is more flexible and will cost them more for the delivery. The licensing rules/laws/agreements must be super fucked up.
SSH connections take For. Eh. Ver. relatively speaking:
gethotbyaddr + getpeername + gethostbyname
Try configuring your DNS correctly; the reason it's fast with Google as a remote host is that their DNS is correctly configured.
No, the reason HTTPS is fast (with respect to a comparison to SSH + gethostbyaddr/etc) is because the webserver isn't doing ANY** reverse DNS. The config change needed would be putting "UseDNS no" in sshd_config.
There are other slow downs as well. For example, HTTPS normally has nothing to do with authentication, but SSH almost always makes a bunch of attempts for various auth types (GSSAPI, host based, public key (DSA, RSA, ECDSA), keyboard interactive, password). There's a fair bit more back-end-forth for ssh. Just do "ssh -vvv exit | grep -i '\(sent\|receive\)'", and compare that to "openssl s_client -connect www.google.com:443".
** in almost all cases this is true, and especially if performance is valued. The most common time it is used is for log resolution (usually done in post-processing) and IP allows by DNS subdomains (which is frowned upon for multiple reasons).
Parent is one side of the "why not". The other is, "why *would* we use ssh for everything?".
The summary (I'm not going to bother reading the article) makes it sound like they want to use ssh in place of HTTPS. That's stupid. We have secure protocols for many things that each fit correctly (ipsec, https, sftp, ssh, various-vpns (ssl/tls/etc), s/mime, pgp/gpg, etc).
The summary says, "SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
WTF? I'm guessing they're referring to public key authentication, which HTTPS has (and I'd assume would work in HTTP/2 as well). You can use client based ssl certs for auth. It's a PITA, just as it would be to use ssh keys - the client side management of said info would need to be solved in a very dumbed down and friendly way.
Some other things it has (and I assume they imply that HTTPS does not have?):
* Binary protocol. ssh just sets up a secure channel. It's not a binary protocol for all the other bits (like shell commands), which are all encrypted plain text. Ditto to HTTPS/SSL/TLS... where's the difference here? HTTP/2 proposal would have a binary protocol, though I don't really see much benefit to that.
* mandatory encryption. ssh = nope. You can, but you could also allow the null cipher. IE. it has to be configured for that way of operations. HTTPS/SSL/TLS - enable HSTS header and do a permenant redirect on port 80 to 443, done.
* key pinning. Oh, you mean like this: https://www.owasp.org/index.ph...
* multiplexing. I'll admit this may be a benefit, but I see little benefit over simply using multiple connections with keepalive. Prove there's an actual performance benefit and then we'll talk. Meanwhile, as parent mentioned, ssh connection establishment is VERY SLOW in comparison to HTTPS.
* compression. You mean like this, "SSLCompression On". http://httpd.apache.org/docs/c...
Please note, I'm not saying HTTP/2 is bad, nor that the features in HTTP/2 fall to the same points above. I'm saying those points do not apply, apply poorly, or already have a better solution in HTTPS as compared to SSH.
Not only is the punishment unjustly targeted, but it harms exactly the _wrong_ people.
Agreed. See Cuba.
How the hell are we making this same mistake so soon after (finally) starting to fix that one?
FWIW, I'm no NK fan. I get that dealing with them is a giant political mess, but that hasn't changed one iota. We should have ripped the bandaid off long ago. Cut it in half (Jonchon to Wonsan) and give China the north and SK the bottom (creating a new land based trade route between SK and mainland China; and getting China port access on the Sea of Japan). I kinda miss the days when the outcome of a war was new territory; now it's like we're playing poker without any chips - worst game ever.
Traveling 3LY instead of 16LY means only having to reach 1/5 the speed to arrive in a "reasonable" time. That's a big help. It might be the difference between doable but hard and hopeless.
Meanwhile, if we wait for that 3LY window, we'll be waiting 250,000 - 470,000 years (15,000 - 29,000 x's as long as it would take to travel at light speed right now).
Let's consider your 1/5th figure... if traveling at 1/5th the speed of light:
* leaving now, it'd take ~80 years
* leaving when we're 3LY away, the travel would take only 15 years, but you have to add on the 250,000 - 470,000 year wait. No society we know of has lasted that long.
If someone happens to swing by close while we're at a high point in society, then go for it, but it's not something I'd try to plan on doing (disclaimer: i have trouble planning what I'll be doing a week or two from now; I still think I'm qualified enough to say we can't plan on the scale of hundreds of thousands of years)
... but no problems with AMD/ATI as of several years now (2D only)... ...and that is important to me because there are just two main vendors in the graphics category.
Slowly it's becoming three, with Intel's HD Graphics and Iris hardware. ...
[bold part by me]
If we're talking about 2d only, then it's definitely at least 3 vendors, and there are some others that are perfectly fine in that realm.
To the AC GP, It's also not at all fair to say you haven't seen any problems for a few years while qualifying that you've only used 2d. The whole damn article is about 3d performance, and that's the part of the driver that is the most complex and has the most proprietary bits. I haven't had any problems with my AMD/ATI cards on my headless servers either, but that's hardly relevant.
People talking about the wonders of open source should do an experiment where they personally actually fix some little thing in one open source project.
Trolls that keep posting crap like this should eat their own dogfood - try it yourself before extolling the horrors, and try it with both the closed source product and the competing open source one. I've done this. IME, you're full of shit.
It's also worth noting that the bug was reported over 90 days ago. "proper fix takes ages"... results will vary wildly depending on the product, the bug report, and the bug, but the majority would be addressable well within that time frame. In most cases, you won't have to do anything as the maintainers will handle it, just like (a good) closed source maintainer would.