Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re:Do it on a lower level. (Score 3, Informative) 227

Well, of course I goofed, it's not that easy (well it is, read on). A snapshot keeps track of what has changed, yes, but it records not the new state, but the old state. What you want to transfer over is the new state. So you can use the snapshot for the location of changed state (for its metadata only), and the parent volume for the actual state.

That's precisely what lvmsync does. That's the tool you want to do what I said above, only that it'll actually work :)

Comment Do it on a lower level. (Score 2) 227

I'd think to use LVM and filesystem snapshots. The snapshot does the trick of journaling your changes and only your changes. You can ship the snapshot over to the backup volume simply by netcat-ing it over the network. The backup's logical volume needs to have same size as the original volume. It's really a minimal-overhead process. Once you create the new snapshot volume on the backup, the kernels on both machines are essentially executing a zero-copy sendfile() syscall. It doesn't get any cheaper than that.

Once the snapshot is transferred, your backup machine can rsync or simply merge the now-mounted snapshot to the parent volume.

Comment Re:They shot themselves in the foot (Score 1) 376

And no, I'm not proposing to do it myself. I just think you haven't thought it all through - it only appears simple; that's why nobody has done it yet. Leveraging the LLVM front-end to extract interfaces from GTK and Qt code would be a tiny aspect of the job, done out of convenience.

Comment Re:They shot themselves in the foot (Score 1) 376

I've looked at some of the papers, and I don't think that such translation would be anywhere in the same order-of-magnitude ballpark of complexity. It's a much bigger job than, say, proving some properties of SSA optimization. Of course I'm only an amateur and whatever I know about programming language semantics is self-learned, but I just don't see how it's anywhere near "easy" if you want to do it right. My gut feel is that, scope-wise, it'd be more along the lines of formal semantics of C and compcert work of Xavier Leroy et al. After all, you need some description of semantics of both the source and target frameworks, and then a way of describing or even just aiding/guiding the transformation between the two. In order to be fit for human consumption, it'd all need to be done in some sort of a declarative framework so that you don't deal with the drudgery. Well, maybe these days it's all a walk in the park for the theorem-prover-wielding yung'uns :)

Comment Re:They shot themselves in the foot (Score 1) 376

Well, said translator would need to include a knowledge base with translation rules. Those rules would need to be expressed in some high level language, with formal semantics and all that. Presumably, to save on the drudgery, many rules would be generated from some descriptions of semantics of "similar" concepts in Gtk and Qt. It would be rather far from simple stuff like pattern matching, and even that was subject to plenty of papers on code generators I'm sure.

Done properly it'd not only be a dissertation-sized piece of work, it would require some original results to implement it in a way that's fun to deal with. I mean, come on, people do master theses with nothing but a description of a C-derived programming language and formal semantics of the same with some proofs. We're talking about something perhaps an order of magnitude harder in scope.

Sure it could be hacked together from a bunch of M4 macros, it's Turing complete after all, right? But that's not what I'm talking about.

Comment Re: Sad, if true (Score 1) 376

Huge hoop, my ass.

Wait a minute, does that mean that you program without using code generation from things higher level than C/C++? I almost can't believe that you can do any big project without speeding up development and avoiding errors and the mundane by generating code in a way that's not really possible merely utilizing the template metaprogramming. Almost anything you do eventually needs a lexer or parser (data formats, comm protocols), state machines, etc. Writing those even in C++ is a big hassle, since the compiler isn't really designed to do arbitrary computation at compile time, and that's ultimately what you need in order to be productive. Yeah, you can do it all by processing bytecodes at runtime, but that bloats your product with fragments of tools that are not needed past build stage. Bloat is bad.

It's really silly IMHO to insist that the make utility, compiler, assembler and linker are on a pedestal, and you're OK using those, but no other tool could ever come into the picture because it's somehow unkosher. Get over it - moc is a code generator, like many others that you're supposed to be using to stay productive. LLVM has got tablegen for a reason - good luck implementing it using template metaprograms to run during C++ compilation, ha ha. Are you going to bitch that LLVM hasn't ever really been C++, too?

Template metaprogramming quickly degenerates into mental masturbation where you express things that take a few lines of easily comprehensible imperative script in a convoluted mess of declarative functional code that makes people who do real functional programming in Haskell or OCaml feel quite happy at not having to deal with C++.

Do you really believe that there is any benefit in re-expressing simple code generators into dozens of template metaprogramming headers that not only slow down the compilation, but are a royal pain to debug should things go wrong? I consider eigen, for example, to be a fairly top-shelf example of what it takes to get C++ to produce well performing numerical code. It's a huge freakin' clusterfuck, and some things still can't be done due to limitations of either C++ spec or of implementations.

I am, in a way, happy about people "disliking" moc. I expect they have a similar religious aversion to other code generating tools. That only makes me more productive and more competitive. So, yeah, thank you.

Comment Re: Sad, if true (Score 2) 376

Signals and slots can be done in C++. Introspection - can't. Moc is not about signals and slots, it's about introspection. Introspection data is then used for signals and slots, but that's just a happy coincidence, because introspection is used for other things too. I'd have hoped people would actually look at the code without repeating the tired old non-arguments. You know, it's pretty damn easy nowadays, no need to download/unarchive the tar ball.

Introspection is not overrated. It's what you need to do the things that are done in Qt, day in, day out. Qt nowadays supports both compile-time-checked and runtime-checked bindings, something that you don't get without introspection. Libsigc++ only solves the compile-time end of the deal.

Comment Re:I have one ... (Score 1) 224

There are many ways for you to go. I've tried all of them except the last one. I love PCIe - good luck doing any of that with legacy parallel buses. In most cases to make it presentable you need to get rid of the DVD drive and replace it with an HDD caddy. There's room left in those letting you add your own hardware - plus you get chassis to bolt/hot-glue your hardware onto.

1. On most any macbook/macbook pro you can replace the built-in mini-PCIe wireless adapter with a serial card. Such cards do exist. Some case mods and soldering are needed to bring the wires out, but you can have native serial ports on it no problem. Been there, done that, the mod even looks presentable. I managed to fit it where the DVD used to be. From outside it looks as if Apple have put it there themselves. The DVD has been replaced with a HDD-carrying caddy anyway, so it was easy to cut out some of the caddy. I've used a mini-PCIe splitter so that I've retained the wireless functionality.

2. On a machine with neither expresscard nor thunderbolt, you can use a mini-PCIe extender to get to an external card cage where you can plug in to your desire. You'll need an intermediate bridge right at the boundary of your laptop's case. That way you plug in the extender into a slot/connector on the case, not on the motherboard.

3. On a machine with expresscard slot, just get an expresscard-to-PCIe-cage extender. You can plugin multiple cards there.

4. On a machine with thunderbolt, get a thunderbolt-to-PCIe-cage extender. Many cards can go there.

5. One could certainly lay out a board with thunderbolt-to-PCIe bridge chip, and a PCIe UART. That way you'd have a small form factor hardcore serial port. I haven't found one yet.

Comment Re:I have one ... (Score 1) 224

By fresh battery do you mean a brand new battery? That's a crappy battery life for sure. I have an early '08 MBP with 6GB of RAM (maxed out), an SSD and HDD in place of optical drive like you do. On a new battery I can pull 6.5hrs of work when using a piece of legacy IDE software on Windows XP running under Fusion, with backlight on minimum (on a transpacific flight). Running Qt Creator with an occasional recompile I can pull close to 8hrs. The HDD is not spinning at that time of course.

Comment Re:Sad, if true (Score 1) 376

MOC provides introspection. Until introspection gets wrapped into C++, there's no way around it. No, template metaprogramming doesn't provide anything to bridge that gap. Seriously. When you use GObject, you're writing all the introspection data yourself, or vala does it for you just like moc does it. How is writing introspection data by hand going to make you more productive I just don't know. Aren't we supposed, you know, to use tools to get rid of menial tasks? Why do C/C++ users generally scoff at code generation if it's a part of a framework? That's just silly IMHO. MOC is a good thing. It saves you from doing stupid shit that the compilers stubbornly refuse to do. Why is that so hard to understand?

Duplication of the standard library was necessary since Qt started when the "standard" libraries weren't so standard at all and had bugs and inconsistencies that were impossible to work around. IIRC Qt 4.x still had to support MSVC 6. There's nothing particularly egregious about having a yet another implementation of a container library that the toolkit can depend on instead of working around the shortcomings and bugs in standard C++ library implementations. I mean, give me a fucking break, you seriously think std::string is anything more than mental masturbation? It's useless at anything that's not an academic exercise.

To see what a large-scale project that uses C++ standard library had to go through over the years, have a look in lyx-devel. LyX is nowhere near as portable as Qt is. It simply won't compile on a lot of platforms that Qt itself compiles on, even though LyX uses Qt, through a platform abstraction layer going back to the times when they used an X-only toolkit and were unsure about whether Qt would "catch on".

COW is not braindead. It simply defers copying until it absolutely has to be done. That's what you had to do to work around lack of rvalue references in pre-C++11. C++ standard library implementations do the very same thing, yet you seem not to bitch about that...

Where is Qt type unsafe when it does not need to be? Do realize that runtime-checked pre-Qt5 signals and slots are typesafe . A type-mismatched connection won't ever crash your program. It may fail and you get a runtime warning on the debug output, but that's it. You can have type safety without full compile-time checking; you seem to confuse the two.

Exactly what good C++ language features does Qt avoid? All that time I was thinking that C++ was a reasonably good indicator at what C++ features do actually work across multiple compilers that people use - as opposed to what the fanboys advocate people must be using or else!, hurr durr.

Comment Re:Misdirected problem (Score 1) 376

They are just not buying new ones because they have reached a level where they are good enough for what they do and have no huge motivation for upgrading.

I've got some anecdotal evidence to back that up. We've got some i7 desktops at work and I don't see any reason to replace them before 2018 or thereabouts, when Windows 8 mainstream support ends. We will upgrade them from Win 7 to Win 8 in December, 2014.

Slashdot Top Deals

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!