Your links are broken; middle-clicking on a link does nothing. Also, please let me decide, if I want to open a link in the same tab (left-click) or in a new tab (middle-click). (Linux/Firefox)
I don't think many projects with such a horrible() distribution system succeeded in the past.
()horrible for package maintainers. Try to create a package from this... There are no releases. I don't see any use of DESTDIR. And bundled libraries are also a major setback. It seems like the developers want to make it as hard as possible to distribute their software.
And I see more and more software going this direction. :(
I don't think configuring e.g. postfix is that difficult:
#
# /etc/postfix/main.cf
#
# disable diff service
biff = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# disable warnings about NIS on mail delivery (default adds nis:mail.aliases)
alias_maps = hash:/etc/aliases
# do not grant special privileges to hosts except localhost
mynetworks_style = host
#set the mailbox size to limit to `unlimited'
mailbox_size_limit = 0
myhostname = fulla.mrothe.de
mydestination = $myhostname, localhost.$mydomain, localhost,
mrothe.de
mailbox_command = procmail -a "$EXTENSION"
And on a backup MX instead of adding your domains to `mydestination` you just set:
[...]
myhostname = blei.mrothe.de
#don't touch mydestination, which defaults to "$myhostname, localhost.$mydomain, localhost"
# accept mail for these domains to be relayed
relay_domains = $mydestination, mrothe.de
I agree it's not that difficult and prior to OpenSMTPD I've been a user of Postfix for 10 years, so I know the software is good and far easier to setup than the big S. ;-)
However, here's a better example of a configuration that is simple with OpenSMTPD and slightly more complex on others:
listen on em0 tls cert "mycert" enable auth
map "vmap" { source plain "/etc/mail/virtual" }
accept from all for virtual "vmap" deliver to maildir
accept for all relay
This will have the daemon listen on all addresses of interface em0 (both IPv4 and IPv6), it will enable STARTTLS using certificate "mycert" and activating authentication for system users (no pop-before-smtp, no cyrus-sasl and whatnot). It will accept mail from anywhere for all virtual domains in the mapping "vmap" and deliver to maildirs, while relaying mails from local users to the world.
That is a fairly basic setup that quite a lot of people use, yet the effort required to achieve similar setup on other software can range from just "slightly irritating" to "extremely painful". Here it's done with 4 lines that are almost readable by someone who has never used the software.
Some other features like relaying through remote MX that require auth; tagging; forcing secure channels; allow more complex setups while retaining the same simple syntax.
/!\ warning: as a major contributor to OpenSMTPD, I'm biased ;-) /!\
I am definitely not in favour of piping curl output to sh and giving root access.
I do prefer packages installed to /usr. You can easily solve the multiple-version-problem: Debian/Ubuntu has `alternatives`; Gentoo has `eselect` etc.
With these tools it is easy to "slot" packages (Gentoo terminology): /usr/bin/meteor would become a link to /usr/bin/meteor-0.1, /usr/bin/meteor-0.2 or whatever. And it is selected by the `alternatives`/`eselect` commands.
And how do you bundle your runtime? Just install the darn package!
If you are using SuSE Solaris95 and all your software is packaged for Debian or RedHat, then you should consider switching to a distribution that makes it easy to install third party software using the native package manager. If that means building a deb or rpm, then so be it; it's not that difficult.
Sorry, I was in a bad mood. I should have written:
This is now how you edit that file. You should edit this file using `visudo`, which "locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors" (quotes text from man page).
My apologies, please let me know how it should be done? You're right, though, all of my other technical knowledge has become null and void because I goofed this part up.
Not the original commenter, but I'm guessing they meant two things:
1) You should technically only be editing /etc/sudoers through visudo.
2) You should also have an admin/root group. All you would need to do then is "sudo adduser <blah> admin/root". This group is the one you specified in /etc/sudoers to have root permissions.
This cutted version feels like none of these persons said anything that is in the video, because the statements (or even words) are "out of context". I just can assume the author of the video has good intentions and did not change the context.
I watched one of the videos and seems accurate enough. The cut left out an important bit from the end of that video. Developing those kinds of thorium reactors would take the US five years with a Manhattan Project style investment. Ten or more years at a slower pace and lower price.
This is by no means cheap and easy, "it's not THAT hard" is a quote that made the cut. I imagine the effort would be comparable to making uranium reactors for power stations which took around thirty years.
I've watched all of the videos-- this is a very good summary of them. Plus, it isn't like the editor/uploader doesn't make it easy to find the original videos anyway.
I don't know about the rules in America, but this circuit design wouldn't be approved for use here in Europe. Circuits are not allowed to draw what is called 'reactive power', because it stresses the grid. Therefore you have to compensate it (in the simplest case using an inductor or a capacitor).
The arguments against large commit size do not hold in this case. If you look at it, the patch consists of a few changes to Makefile.am, configure.ac, man/intel.man, src/Makefile.am, and src/intel_module.c, which contain no significant logic, and completely new files in the directories src/sna/ and test/. It's one new feature that is practically self-contained, so I don't see any sense in splitting it up into smaller commits.
The article says that the Kindle supports EPUB. As far as I know* it does not support this format. And it's one reason I won't buy a Kindle any time soon.
The Nikkei is sometimes incorrect about technical details (it's a financial paper after all), and the mention of EPUB on Kindle could be their misunderstanding or just a wild speculation, which is their another trait.
The original article online appears to be behind the pay wall, and I couldn't find relevant article on paper, so this is just a guess...
