Only a fool would be OK with cloud based control and automation. If all the processing and control is not done on the local LAN then the product is 100% crap.
And yes I am calling most of this consumer "smart home" products utter crap.
Being paid to program doesn't make you a professional.
Being paid to do anything by definition makes you a professional. Professional does not mean 'better', it just carries the connotation since frequently someone who cannot get paid for their work where another can is due to things that lack. In coding, sometimes being 'professional' versus 'amatuer' really boils down to being loud enough to get taken seriously.
People have reported corrupt log files. The result is all the data is unrecoverable. The complaints have been answered 'as designed'.
When things are right, it works as intended. When things are bad, it can go far off the rails. Considering it is the system log used to debug what is wrong when things are off the rails, a full binary log is a dubious proposition.
There are benefits to binary log, but they could have been done to varying degrees with structured text and/or external binary metadata, rather than a corruptable binary blob.
Intentionally used.
It happens when someone in management or preliminary design fucks up in the early conceptual stage. So fear and panic are used to keep everyone's head down instead of looking around, asking who made these shitty design decisions.
I hope their home offering isn't like the TV remotes, where to get it to work, I had to create an account with them (with demands for a lot of personal info), go through their relatively awkward website to find the televisionI was using, have that downloaded to the device via USB, and then add some configuring after that before the remote could be used as a remote.
Heck with that. If a remote can't offer an interface to locate stuff on the device itself, it should at least not require an Internet connection (the application should handle this, perhaps downloading codes for newer items), and definitely not require registration on a website to be used.
These games should have been released for android/IOS years ago.. they would have made a buttload of money off of that old IP.
If they are just going to sit on it they need to release it and let people that are not lazy make it come back to life.
http://www.amazon.com/SanDisk-...
LIMITATION OF LIABILITY:
SanDisk's liability is limited to replacement of product or refund.
*30 years warranty in regions not recognizing lifetime limited.
NOBODY has a warranty of data readability. even enterprise grade SDLT tapes have no warranty of the data being readable more than 30 milliseconds after being written. They will just replace the tape if "defective".
That is a valid complaint. Adding functionality so startup is parallel is one thing. Having one's own binary log format [1] is a big downside. To boot, rsyslog uses cryptographically signed logs. That means that I lose protection on systemd's logs because in theory an attacker could tamper with those. Should the logs go to rsyslog, the files either will show tampering or be missing.
This also prevents logging to a remote machine as well.
I'm not a fan of binary logs. Even AIX will log stuff from the errpt command if you turn on the right syslog settings. Binary logs make a program like Splunk a necessity, and that is not a cheap tool once you start talking about gigs a day hitting your index servers.
[1]: I don't like the "pro" for it saying that journalctl can give you just the info that you need. For the info I need, I have grep, egrep, and many other tools.
Religious sentiments aside, systemd scratches a number of itches that eventually needed to be addressed. The main one is parallel startup of daemons. On a SSD based machine (and note, these are anecdotal runs), CentOS 6.5 takes about a minute to fully boot to a login prompt. On CentOS 7.0 with systemd starting anything that isn't relying on another process at the same time, well under ten seconds. Similar with a shutdown.
The second item is being able to place processes in containers and set limits before they start. This can be done with SVR4 startup with wrapper scripts, but systemd makes it easier.
The main thing I see against systemd is that it is new. I remember pushback in the early 1990s when Linux distros went to the SVR4 way of starting up from having everything in a big
The second downside is that systemd has more moving parts. However, it will only be a matter of time before the bugs get eradicated. Heck, sendmail used to be the hair-puller for sysadmins and even that beast is now a long since solved problem.
If one wants to gripe about something, gripe about firewallD. For bringing Windows type abstraction to Linux, it is great. Anything else, it is just another questionable layer that is of dubious value at best, a potential vulnerability at worst.
Where do you stand? at a better job at a different company.
you can hide under your desk and hope your master will praise you, or you can demand being treated like a professional and demand the respect and be treated as an employee and not a slave.
Anyone can make an omelet with eggs. The trick is to make one with none.
