Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
User Journal

Journal Journal: Best simple SID to USB connection? 3

That may not be a good way to describe it but... I have a C64 I never use and I think I shall desolder its SID before consigning it to recycling since they are now officially hard to come by. What can I put it on that will let me use it efficiently?

User Journal

Journal Journal: The lameness filter is broken (again) 13

Your comments "spectacularly brain-damaged suggestion" and "drug-fueled" are why I consider your post troll like.

The above quote rendered one of my comments unpostable...

User Journal

Journal Journal: Best Foakleys? 5

Surely someone around here knows where's the best slightly-reputable site to buy some knockoffs of the Oakley M2 XLs. I want to try them out for a while and see how they feel on my head. The sites I've found so far are registered straight outta China. Oakley has successfully driven the fakes off eBay and Amazon... the problem is, I'm not going to drop two hundred bucks on some glasses that might give me a headache, like most glasses do.

User Journal

Journal Journal: Apple ID being used for harassment and ID theft 9

Apple is now actively, willingly, and deliberately aiding in online harassment and identity theft against me. They refuse to destroy an Apple ID which has been created with my email address, to which I do not have the answers to the "secret questions". They will not permit me to proceed any further without having an attorney.

What do I do now? Who do I call for relief? I can't afford a legal battle with Apple. I don't have an attorney on retainer.ï

User Journal

Journal Journal: Vroom.

Finally, I got my A8 Quattro up to the point where I could get it smogged. Registration and rubber to follow imminently. Crap, this thing is quick.

User Journal

Journal Journal: systemd 13 - on the impossibility of automated monitoring 2

One of the design goals of systemd is to check if services are running, and restart them automatically if they aren't. One of the criticisms is that this should be done in the daemon, not in systemd (for various reasons, one of which is addressed here).

In some cases it's easy to detect if a daemon has failed: when the daemon no longer has any processes running, you know it has failed. That's a fairly trivial case of course, and you'd hope the daemon is well written so it doesn't crash.

But that's not really what you want, what you want is to make sure the service is still up and responding correctly. There is no automated way to do that. In other words, you need to have deeper knowledge of the daemon in order to make sure it is still running.

One idea: you could have the service send a message to systemd every few seconds, letting systemd know it is alive. This is a heartbeat, but it is again relying on the writer of the daemon to make sure he does it correctly. If you've seen a lot of code, then you know that someone will set the heartbeat message to send in a separate thread, and you'll end up with a situation where the entire program has deadlocked, and nothing is running except the heartbeat thread.

These are the limitations systemd lives with: the limitations any monitoring system would live with; that automatic monitoring of processes is not really possible. If processes are crashing often, the answer isn't to improve monitoring, it's to fix the process.

I've written other entries (some positive some negative) about systemd here. The big problem I see with systemd is outlined here.

User Journal

Journal Journal: systemd 12 - how large is pid 1? 15

Systemd pid 1 takes up 1.5 megabytes on my Fedora system hard drive. For comparison, sysvinit compiles down to 40k. For security purposes, smaller is better, but getting the interfaces right is far more important.

So what is systemd doing with that 1.5 megabytes of compiled code? To answer that question, we find a good place to start, src/core/main.c, which is 2085 lines long. That is not necessarily too long, but if you are a fan of short functions, you will be horrified to learn that the main function is 825 lines long.

Typically a long function starts out well organized, but as people add to it over time, it becomes more and more chaotic, and that is starting to happen here. It is not always clear the order of why things happen, for example. If I were going to refactor this, it would look something like this:

main() {
    init();
    main_loop();
    cleanup();
}

So what is it doing with all those 825 lines of code? I went through and made a rough outline, which I wrote in code form. It could be further simplified, of course, but this will give you a basic understanding of what is in the main function, and it's better than 825 lines of chaotic code:

int main(void) {
 
  getTimestamp();
  parseSomeCommandlineArgs();
  setPIDNameToSystemd();
  setUMaskToZeroIfRequired();
 
  initFilesystems();
  initSELinux();
  initSMACK();
  initIMA();
  initKernelClocks();
  initLogging();
 
  initDefaultUnit();
  initJoinControllers();
 
  mountKernelVirtualFilesystems();
  initSignalHandlers();
  parse_Config_Commandline_Environment_and_KernelCommandLine();
  daemonize();
 
  initIfRunningAsManagerSystem();
  initIfRunningAsManagerUser();
  managerSetup();
 
  setCapabilityBounding();
  enforceSyscallArchitectures();
 
  queueDefaultJob();
 
  do{
      runMainLoop();
  }while(handleStateChange());
 
  reexecuteIfNeeded();
 
  cleanupAndShutdown();
}

I tried pasting the original function here so you could compare, but Slashdot apparently doesn't allow posts that long and chopped it off. If you want to see it, you'll have to put some extra effort in and click on this link.

When code gets too long, you need to break it into smaller pieces, so the human brain can see how the code is organized. When you refactor like this, it's important to make sure that the refactored code shows the overall structure, rather than obscuring it.

As always, please comment or correct me below, I am interested in hearing what you think!
(I've written other reviews, too, check them out).

User Journal

Journal Journal: Punitive Between-Comment delay? 4

I have Excellent karma, as usual, but I have a five minute delay between my posts. It seems to have appeared on my account again after the last time I said something mean about a Slashdot "editor". Is this something that Slashdot has done to everyone recently, or is it a punitive action against me specifically by one of the "editors"?

User Journal

Journal Journal: Systemd 11 - Open Source Makes Things Better 9

In some ways, I think of Lennart Poettering as a product manager. He figures out what people want, then builds it. The architecture is not always the best, but 'customers' don't tend to care. The point here is that some people do want some of the features of systemd, and Lennart figured that out.

Lennart's system is sometimes laughably bad (for example, he'd prefer to get rid of BSD because he doesn't know how to write portable software), but he has done the community a service by bringing up the topic of system init. More and more, we are seeing thought provoking commentary, ideas on what a good init should be like. This wouldn't have happened if Lennart hadn't built systemd.

This is how the community should be. One person sees the problem, and tries to solve it. Other people come and say, "I can think of a way to improve that." Eventually we arrive at a solution that is elegant, and effective. Init systems have been controversial for decades, which is why BSD and SysVinit are different. Every major Unix vendor has tried to come up with a solution to that problem, and in each case come up with something rather mediocre. Until recently, the Linux and BSD communities have kept what they had, preferring not to change until something comes that is clearly better. When the better answer comes along, it will be obvious.

Systemd won't be here for the long term, but it's effects will be felt through spurring the community to solve this problem that has plagued the community for decades, again, analyzing the problem with things like this (I'd also like to think my own analysis is worth something).

I think a good start would be to add functions to POSIX like "daemonize()" and "start_dameonize()" "complete_daemonize()" but maybe I'm wrong.

User Journal

Journal Journal: systemd 10 - code structure (a random-seed example) 18

As an intermezzo while investigating the stability of APIs (since that's not a fun thing to do), here is an analysis of some code: examining random-seed.c, pulled September 1st, 2015 ( link here, for as long as github is around).

When you come across a piece of code, the first thing you ask is, "what does this do?" In this piece of code, you can see the main() on line 34, so we know it's a stand-alone utility. That is the only function in a 165 line file, so come on Poettering, break your code into easy to read functions. It's not 1985 anymore.

Since it's not clear what the utility does from the comments, a web search might be helpful, which finds the man page, which doesn't tell you much. For example, on line 44 of random-seed.c, we can see that a command-line argument is required. However, the man page doesn't tell you what options are available, it's biggest use is telling you where the seed is stored on the filesystem (if you're wondering where that file location is defined, it's in the Makefile.am). The documentation is bad.

The program itself isn't helpful either, it doesn't respond to the --help option. If you give it any option that is not correct, it responds "Unknown verb '%s'." So keep guessing random verbs until you get the correct option.

Moving along to my main complaint, you have to read many lines of this file before you understand what it does. A program like this can be mostly self-documenting, if you structure main correctly. Here is an example of how it could be.

int main(int argc, char **argv) {
      init();
      parseCommandLineArgs();

    if(shouldLoad) {
              writeSeedFromFileToDevUrandom();
    }
    else if(shouldSave) {
              writeSeedFromDevToFile();
    }
      return 0;
}

This can still be improved. There can be comments explaining why things happen. It is much easier to see what the program does when it's broken up like this. The main algorithm should be clear.

One more serious criticism about this file, hard-coding the output file in Makefile.am is double bad: first because it shouldn't be hardcoded, it should be a command-line option. Second because build files should store as little information as possible.

That's a lot of criticism, but they're relatively minor. With a few fixes, the code is cleaned up. The big problems in systemd, the things that really worry me, were mentioned in journal 9. Those are the things that will cause serious degradation over time, and problems for all of us.

User Journal

Journal Journal: FizzBuzz in Swift

The following is my prepared answer for anyone who asks me this stupid fucking question in any interview in the future.

extension Int
{
  func modBool(modulus: Int) -> Bool
  {
  return (self % modulus).boolValue
  }
}
 
for x in 1...100
{
  print((x.modBool(3) ? "" : "Fuck ") +
    (x.modBool(5) ? "" : "You") +
    ((x.modBool(3) && x.modBool(5)) ? "\(x)" : ""))
}

-jcr

User Journal

Journal Journal: Why libressl is stupid 2

I really want to like libressl. But it pretends to be openssl badly. They refused a patch that would have mitigated this whole RAND_egd problem by simply returning that it doesn't work when someone tries to use it, which means that you commonly need a patch to use it at all. If it's not going to work like openssl, then it shouldn't occupy the same space in the filesystem.

Slashdot Top Deals

An adequate bootstrap is a contradiction in terms.

Working...