There are plenty of good people in India, but they don't come cheap either. And they want some career perspective too and not some sweatshop with conference calls with the US-based manager at 3AM.
Pay peanuts, get monkeys is a universal truth.
472 publicly visible posts • joined 25 Sep 2014
systemd
-free Devuan hits stable 1.0.0 status
I would consider OSS better. It is a very Unix-like interface. You just use standard Unix open() and write() system calls to write raw audio data to /dev/dsp.
You can even just 'cat' raw audio data and redirect into /dev/dsp.
Similarly, capturing sound from the microphone just involves the read() system call on /dev/dsp .
/* sinit (2014)
* http://core.suckless.org/sinit
* Because complexity killed the cat.
*/
# MIT license.
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define LEN(x) (sizeof (x) / sizeof *(x))
static void sigpoweroff(void);
static void sigreap(void);
static void sigreboot(void);
static void spawn(char *const []);
static struct {
int sig;
void (*handler)(void);
} sigmap[] = {
{ SIGUSR1, sigpoweroff },
{ SIGCHLD, sigreap },
{ SIGINT, sigreboot },
};
static char *const rcinitcmd[] = { "/bin/rc.init", NULL };
static char *const rcrebootcmd[] = { "/bin/rc.shutdown", "reboot", NULL };
static char *const rcpoweroffcmd[] = { "/bin/rc.shutdown", "poweroff", NULL };
static sigset_t set;
int
main(void)
{
int sig;
size_t i;
if (getpid() != 1)
return 1;
chdir("/");
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, NULL);
spawn(rcinitcmd);
while (1) {
sigwait(&set, &sig);
for (i = 0; i < LEN(sigmap); i++) {
if (sigmap[i].sig == sig) {
sigmap[i].handler();
break;
}
}
}
/* not reachable */
return 0;
}
static void
sigpoweroff(void)
{
spawn(rcpoweroffcmd);
}
static void
sigreap(void)
{
while (waitpid(-1, NULL, WNOHANG) > 0)
;
}
static void
sigreboot(void)
{
spawn(rcrebootcmd);
}
static void
spawn(char *const argv[])
{
pid_t pid;
pid = fork();
if (pid < 0) {
perror("fork");
} else if (pid == 0) {
sigprocmask(SIG_UNBLOCK, &set, NULL);
setsid();
execvp(argv[0], argv);
perror("execvp");
_exit(1);
}
}
Is the heavy-handed tactics Red Hat have used to force this down everybody's necks.
Both Gnome and systemd are basically Red Hat projects. Gnome is pretty popular, and the systemd people have used that to force systemd upon everybody's distribution by making Gnome absolutely depend on systemd.
Canonical tried for a time very hard to have their own non-RedHat init by trying to reimplement the systemd protocols in their own daemons. Surprise, surprise, every bl**dy point release of Gnome somehow changed the protocols and broke Ubuntu's daemons. It may not have been intentional sabotage but it was certainly not distinguishable from it by its effect.
To me these tactics remind me a bit too much of the famous tactics of a certain Redmond-based company.
"Gnome ain't done until alternative init's won't run."
With respect to the actual systemd code, I think it has its architectural problems, but the real issue is the effective stranglehold Red Hat has gotten on the init world. So for example, yes you can fork systemd, but it is extremely likely that Gnome will then suddenly change its protocols again. And your fork will be broken.
That's actually a bit unclear, if the total repo is 300gb or a single branch. But note that git pulls one branch at a time so the relevant number for scalability is the size of a single branch.
To put into perspective how ridiculously large this is: the source code for the entirety of Debian is about 270GB. And that contains a vast suite of applications: everything from EDA tools to several office suits to multiple browsers to compilers to FPS games. A total of 28 thousand different packages. Windows is big but not that big
Given this, it is almost a certainty that the 300GB is not just source code. Perhaps it contains the entire build chain. Perhaps they are storing build artefacts in the repo.
There are tons of companies which store source to all their products, and presumably their tax returns and porn stash, in a single giant repo. Perforce and ClearCase actually encourage such a way of working.
Now those companies may want to use "git", but of course not to the extent that they would change their way of working and split up their repo a bit. So now they can buy "Microsoft git" which presumably has some token integration with actual git, but for the 30gb repo support you have to use Visual Studio and not the normal git client.
I suppose "embrace and extend" is still a thing at MS.
For laptop usage, an SSD probably outlast a HHD. For a data center, that would be a different matter.
SSD wears out due to write actions. In a data center, it gets hammered 24 hours per day by write requests and this becomes very relevant. A laptop is comparatively speaking "always" idling and can probably handle an order of magnitude more writes than it will see in its economic lifespan.
Then there is the point that laptops get pummeled around, which the mechanical parts in the HDD don't like. In the data center the HDD is presumably nicely mounted so that this isn't an issue.
I'd suggest a refurbished Surface 3 if you want to run Linux. Apparently complete support for the Surface 3 landed in kernel 4.8.
Newer hardware is always tricky, it takes a while for driver support to materialize. Getting slightly older hardware means better driver support and saves you some money too.
@ Whiznot
I am using the ShutUp10 tool which is presumably similar. However, these tools don't fox the underlying trust problem.
1. There is no way for me to judge their effectiveness.
2. They operate by changing various low-level setting, i.e. in essence they just ask the OS nicely not to spy on me. Even if that is effective today, MS can decide to stop honoring those requests with any update. And how would I know? See also point 1.
Stephan
I am actually fairly happy with Windows 10 (after installing Classic Shell), but the telemetry worries me a *lot*.
Perhaps I am just overly paranoid, but *by their own admission* Microsoft reserves the right to download documents (as in "actual files I own") from my machine. All for good intentions, presumably.
MS, please stop faffing around with Hololens and Cortana and give me a kill switch for the telemetry.
Thanks,
Stephan
I have this system here which is completely bot-based.
There is a top bot called "bash" which takes instructions from me, and redirects them to other bots. I have a bot called "grep" which is good in searching files, and a bot called "ls" which can tell me about my files.
There is also a bot called "vim" but he is a bit weird since he insists on a "visual interface". Fortunately, if you call him "ex" he becomes reasonable and just wants to talk.
Actually they still make mainframes and minis but their marketing is quite effective in hushing it up.
For example, at pub400.com you can get a free account to play around with IBM I (aka AS/400, what IBM calls their "midrange" OS). Now this is cool, but it is hosted by a company called RKZH, *not* by IBM.
So why doesn't IBM hand out some free accounts for non-commercial use to nerds like me? Hey IBM, you know, if more people actually *knew* about your products you might sell some more.
"Approximately nobody buys phones sim-only"? [1]
That statement can only be considered approximately true in the US market, in many markets sim-only is important. And not just in India. In the Netherlands we have 36% of all phone contracts as sim-only.
[1] That should be "sim-free", of course. But who wishes to be a pendant and hang from somebody's neck?
The funny thing is, when I first started with Linux somewhere in the mid-90's, twm was considered rather bloatware. It had less functionality than fvwm while taking entire megabytes of memory (I think it also tended to leak memory, so usage would go up over time.)
So generally fvwm was recommended. X11 barely ran on my 486 DX with 4MB with fvwm (8MB was really the minimum recommended configuration at the time.)
Next week, based on the feedback of Fortune 500 CIO's, who will, in no uncertain words, explain that forced yearly Windows updates == full-company RHEL desktop rollout, we will be surprised with the new Windows 10 LTS. (Enterprise SKU only, of course. Not for you, lowly Windows Professional peon.)
And who can conceive what unfathomable wonders Microsoft policies will bring two weeks from now?
While I agree in general, in this specific case (open source project vs commercial derived version), it makes a lot of sense to give it different names.
This all goes back to the original conflict between Mozilla and Debian about inclusion of Firefox in Debian. Mozilla basically said: fine, we trust you Debian people to distribute a Firefox executable, but we don't want anybody building a (possibly malware-infested) custom version of Firefox and slapping our Firefox brand on it. Debian said: but allowing our users to make any bl**dy change they like and redistribute the result is the whole point of Debian.
In the end, the conflict was resolved by re-naming the Debian version of Firefox as "Iceweasel" and removing any reference to "Firefox". Confusing? Yes, but given the nature of branding and open source the only possible solution.
Since then, people have wizened up and starting to give their open source projects names different from the commercially-supported version to begin with. Consider Chrome/Chromium, but also PhoneGap/Cordova. So this move fits into an established pattern.
So if I understand correctly, the relation between Moby and Docker is similar to Chromium vs Chrome. Moby/Chromium is the open source "white-label" variant, and Docker/Chrome is the Officially Supported and Branded (TM)(R) version.
Somewhat confusing since the command you actually run to manage your containers in Moby is (still) called "docker".
It basically doesn't run in a 1GB Linux VM, requires at least 2 GB to get to some screeching action.
Firefox runs fine in 1GB.
Also Firefox on Android is great, provides lots of privacy-protection add-ons. Which are strangely missing from the Android version of Chrome.
There was a time that Chrome was faster than Firefox, that time is long past now.
To be completely frank: while I sympathize with the people who lost their job, it is a good thing we get rid of Unity and Mir (especially Mir). The second-to-last thing Linux needs is yet another desktop environment, and the very last thing it needs is yet another display server.
The technical rationale why Ubuntu couldn't just use Wayland like everybody else always seemed pretty thin.
Perhaps connecting a telnet client to port 80 is a fun and educational exercise. However this device runs a telnet *server*. Telnet sends (typically) arbitrary shell commands over a plaintext connection, so anybody who can send packages to the telnet port can 0wn the device.
Unfortunately BusyBox contains a built-in telnet server and no ssh server, so any security-unaware IOT engineer (please excuse the tautology) will choose the path of least resistance and use telnetd instead of sshd.
The Linux community "as a whole" will not help because
1. It is a community like the "community of nations", i.e. not a community at all.
2. It has mostly given up on conquering the desktop market and is now content with owning the server and mobile markets. (See recent Ubuntu news.)
3. It is not interested in solving this problem since it doesn't affect them.
Perhaps the Windows community "as a whole" could grow a spine and do something about it, though.