feld

PolarSSL is now mBedTLS

Dedup was rushed. This is supported by the original authors. I believe it was discussed in detail in a presentation by Matthew Ahrens. If I could remember the specific source I would link it, but it did not get the same level of testing and care as other features.

Conpression is fine. Dedup has always been the problem because it was rushed.

XMPP is terribly fragmented and the clients all suck.

They spent years and untold amounts of money on the body design. They cannot change it without affecting their drag coefficient and killing their max range. The body design is part of the magic that makes the Tesla possible.

edit: drove my friend's Model S down the highway at 75mph and put down the windows. No air entered the cabin. We sliced through the air like a hot knife through butter. It was remarkable. Also consider that they are legislating to get the requirement for side mirrors removed. If they replace them with cameras they gain 7% more range.

afaik Tesla is the most aerodynamic road legal car in the USA

No, use anycast or VRRP/CARP for Postgres servers. Use a watchdog script to monitor for master failure. When it fails, the secondary/slave IP becomes live. Watchdog script should take necessary action to make it recognize it is master/writable. Clients don't have to know what happened.

Bringing the master back live and making it primary is a more difficult task. I would not want to automate this anyway as it would be too easy to shoot your foot off.

I'm using their product. Let me tell my story.

I have an old garage door opener -- ancient Craftsman. It doesn't even have a secure RF opener; no rollover codes or faux-crypto. My wife lost her garage door opener remote. I looked for replacements and couldn't find any that were less than $40 new or $30 used. Ridiculous.

I have an outdoor keypad on the garage, which is detached. It doesn't work very well in the extreme cold because the 9V battery gives out. This solves a unique problem for me: I do not want to buy a new garage door opener. Mine was recently rebuilt with new gears and should be good to go for years. Further, would be a few hundred dollars without labor, and I don't want to do the labor myself. I've done it before; not worth my time. Now, Garadget exists. I got mine for $69. Now I have infinite remotes as long as my wifi works (It's on my IoT VLAN which only can do outbound 80 and 443).

So, Garadget solved a unique problem for me in 5 minutes of work and saved me money. Hilarious that a device this advanced is cheaper than a simple RF remote, but that's supply and demand in action.

Now is this a security concern for me? No. If someone wants to break into my garage they can eBay some garage door keys and just disengage the garage door from the opener via the keyhole on the front of every modern garage door. Or pick it I guess? Or they could get a kids toy and reprogram it to brute force all the garage doors in the neighborhood. https://youtu.be/iSSRaIU9_Vc

tl;dr while this is the Internet of Silly Things, this is not a security concern for me. If someone hacks the company servers and starts opening and closing my garage door I'll just unplug it or remotely block it from my network.

Ooh I wonder if this is based on Dummynet

I think the EVVA MCS is one of the most interesting locks because of the clever use of magnets for bitting

http://www.evva.co.uk/products/mechanical-locking-systems/mc...

that's why you use dnscrypt-proxy

Cisco doesn't log the traffic. Don't believe me, just ask davidu who founded OpenDNS and resides at Cisco.

I've a wild idea: add support for pledge, capsicum, etc to your codebase so these vulns are neutralized on every OS with a good security framework

Why didn't you use the classic webserver.example.edu/~$username ? Your current implementation would be a nightmare to admin in comparison

This is _illegal_

In the eyes of theists it is the union of two humans in the eyes of God. I think in 2017 it's time we start calling this fairy-tale bullshit out instead of stating it as fact.

when the RAID is handled by a different layer you lose some very important integrity features

I maintain that System and Distribution are not compatible by definition.

Distribution: A spatial or temporal array of objects or events.

System: A group of interacting, interrelated, or interdependent elements forming a complex whole.

I admit I am not an expert in language, but I have yet to see an explanation of how these two terms mean the same thing.

Except it's not. If I hit a bug in the NFS code, who at Debian will help me? Nobody. The bug report is opened and the buck is passed upstream. Now they have to hope the upstream maintainers of the NFS code care to fix it. They might not be interested especially if the distro is shipping an older release they no longer wish to maintain.

If I hit a bug in the NFS code on FreeBSD, I open a bugzilla issue first, but get the attention of Rick Macklem. If I hit a bug in the posix shell, I contact Jamie Gritton. If I hit a bug in the VM subsystem, I want to talk to Konstantin Belousov. A weird timekeeping issue? Most likely our resident Time Lord, Poul-Henning Kamp. A C conformance issue? Presumably David Chisnall. Even our compilers have patches required for our codebases, so we have compiler maintainers. If I hit a bug I have a team of people to reach out to.

All of these people have a vested interest in bugfixes and maintaining the code within our supported releases. You do not have this luxury in the Linux world. At best you can hope you have a support contract with RedHat or someone who can pay a competent employee to figure out how to fix it if upstream refuses to get involved.

An OS is a kernel and userland developed together in its entirety. All the code shipped is maintained by a single responsible entity: an open source team or a company. External code is imported into the source tree and treated as if it is owned by the team. Any patches required for it to integrate cleanly are the responsibility of the OS maintainers.

A distro is a Linux kernel and a collection of open source software, typically GNU, which fulfills the needs of the userland environment. The distro maintainers are responsible for packaging and distribution. They are not responsible for maintaining the kernel or any of the userland software unless it was internally developed such as a custom installer or various glue code, maintenance scripts, etc. They do not own the libc, the kernel, the shell, any drivers, responsibility for writing security patches, or bug fixes for any code they did not originally write, etc. The distro volunteers or employees of the company in charge of producing the distro may be involved in kernel or other open source softeare development, but it is not required.

This may be an unpopular statement, but a Linux distro is not an OS.

It is a collection of open source software that tries to be compatible with all of its components. Subject matter experts of all components are usually not involved in its creation. Instead they exist spread out across the entire Linux distro ecosystem.

Does Arch Linux have an expert in the virtual memory subsystem of the kernels they ship?

Does Gentoo have an expert in the kernel random code?

Does Debian have an expert in the glibc codebase?

Does Ubuntu have an expert in the bootloader?

Does Mint Linux have an expert in the BASH code they ship?

I can say with confidence that Suse and Redhat employ experts of many areas of the kernel, glibc, systemd, filesystems, and other components, but not everything.

Does FreeBSD/Dragonfly/OpenBSD have an expert or designated owner of the filesystems they ship? Bootloaders? Libc? Kernel timekeeping code? Random? Crypto? VFS? Network stack? NIC drivers? CPU schedulers? Shells and userland utilities?

Yes they do. They're OSes, entirely maintained in-project. Just like Windows, OSX, Solaris, etc.

OpenBSD is most aggressive here, but unmaintained code usually means nobody is using it and it will be removed. Everything has an owner and is constantly being looked after. In the BSD world it would not be common for a major component to exist long term without an SME joining the project and maintaining it or replacing it.

BSDs are OSes, and are mostly independent. You cannot easily port kernel code between them because they have diverged significantly.

mBed TLS was previously known as PolarSSL. This is software, not hardware

Dental/oral health is crucial. You can die from dental problems. I will never understand why the entire dental industry is treated as if it is cosmetic or non-essential. Stress to your immune system and failure of major organs is not taken seriously, but it is a very real risk.

yellow line on road seems to perfectly align with the yellow barrier. camera didn't identify the wall. I don't think they have radar to identify solid objects, do they? Isn't it just camera? I can't remember right now and too lazy to look it up.

Because I don't want my friends and family and neighbors to suffer and die

Because they didn't add provisions to control pharma and hospital gouging. Let them run free and they'll suck you dry.

mind posting more info about this somewhere?

I'm not sure that is something that could be "fixed" in 16.04 unless you can convince the Ubuntu kernel maintainers to backport patches for PCI-E hotplug / thunderbolt support.

just want to point out: vast knowledge of telephony/VOIP is not something every sysadmin should be expected to know. If you don't have telephony expertise on staff I hesitate to suggest someone build out a VOIP infrastructure on their own. It can be extremely time consuming to learn and it is definitely painful to troubleshoot.

Yes

VOIP is considerably better than PSTN if configured correctly. There's no comparison. Your sysadmins don't understand VOIP.

Both ends need to support wideband codecs, as does your phone (hard or soft phone). This includes the VOIP providers needing to be able to use wideband codecs between each other.

If you achieve a wideband setup the call quality is amazing. I've used it for years. It really sucks when you have to call someone on a legacy POTS line or using a narrow band codec (bad voip, cell phones, etc)

On that note it's unfortunate that cell phones which can do wideband codecs within the same carrier (HD Voice!) won't work if your call leaves their network.