Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:I call bullshit (Score 1) 166

by rdnetto (#49339029) Attached to: Internet of Things Endangered By Inaccurate Network Time, Says NIST

There's a difference between elapsed time locally and globally. Locally (i.e. on a single processor), you can have some meaningful concept of absolute time (i.e. whenever the timer interrupt fires). The moment you introduce a second processor, you run into issues where they can be ticking at different rates, and the non-trivial delay in communications between them means that you can't ever hope to synchronize them to the extent you can assume they are the same.

For most applications, you can get away with fairly large tolerances. e.g. wifi is probably fine with 1% variations in your concept of how long a second is. But that only works because you're using local elapsed time. If you need to compare timestamps from multiple nodes (global absolute time), you need to use approaches like vector clocks, because otherwise there's no meaningful way to reason about whether two events happened before each other.

tldr; protocols like wifi just need elapsed time to be roughly correct. Comparing timestamps between systems is much, much more complicated, and you can't even infer an ordering for the general case without casuality. (In that sense, there are a lot of parallels with relativity.)

Comment: Re:Join the mailing list (Score 1) 15

by rdnetto (#49285617) Attached to: Kolab Summit 2015 Announced

Kolab supports multi-domain, in fact even ASP multi-tenancy, environments. And seamless updates and upgrades are part of the enterprise values it provides under support. But naturally one needs to know what they are doing. This is a complex micro-service architecture that is more powerful than virtually any of the competitors. But that power comes at the cost of loads of opportunities to shoot yourself in the foot.

I think is simultaneously the best thing and the second biggest issue[1] about Kolab - it's a very powerful piece of software targeted at sysadmins. You can setup some very complex, enterprise grade configurations with it, but to do that you need to be willing to muck around with postfix, etc. By that same note, you need to have at least basic familiarity with postfix, apache, cyrus, etc. to actually set it up in the first place, which sets the bar fairly high. (I think it took me a week of practicing in a VM before I was ready to do a proper deployment on my home server.)

[1] The biggest issue would be its general bugginess. e.g. This bug affects anyone with an apostrophe in their name, but went untouched for over a year, despite a patch being included in the original submission.

Comment: Re:Does anyone actually use this? (Score 1) 15

by rdnetto (#49285489) Attached to: Kolab Summit 2015 Announced

I've been using it for little over a year (for the same reason as you - didn't want to put too much info into Google), and would describe it as half-decent. I use it as a diary, essentially - schedule, calender, todo list, etc. I still use Gmail for actual email though, because unless you own the domain outright (i.e. not a subdomain) you can trigger false positives for spam on other servers that results in you mail being dropped.

Pros:
-open source
-free (gratis)
-works

Cons:
-pain to setup - the target audience is sysadmins, so you really need to practice doing it in a VM first (especially since doing a complete uninstall is non-trivial)
-buggy - every time I've upgraded to a new version, I've run into a significant bug. (Inability to handle apostrophes in names, buggy apache module that keeps crashing the server, etc.) You can usually fix it if you know PHP/Python, but it's still a pain that makes for a poor user experience. (I've submitted bug reports with patches for these, but not all of them have been merged.)

Basically, it does take a lot of effort to get it working (I have 500 lines of notes on it), but once you've done that it will keep working pretty reliably. The official client is KDE Kontact, which works great for me since I use Linux anyway. I can see it working out poorly if your OS is Windows though (KDE for Windows isn't stable yet). It syncs well with Android too. I generally prefer to enter important events, etc. in through the webui though, since I don't quite trust the other clients to sync them properly.

tldr; it's probably the most broken piece of software I've used under Linux, but it works well enough that I continue to do so. I wouldn't recommend it for anything important (e.g. actual business use), but it's fine for non-critical personal use.

Comment: Re:Don't be so sure of that! (Score 1) 93

by rdnetto (#49260587) Attached to: Linux Kernel Adopts 'Code of Conflict'

Linus' leadership role is on its way out, I fear. Linux is done, too. It's suffering from the same disease that has affected GNOME, Firefox and Debian: technological correctness taking a backseat to political correctness. It's no longer considered acceptable to point out technical flaws with people's work. Instead, shitty software is accepted and even admired in some cases, while those who stand for doing things right get treated like utter shit and censored.

Linus isn't going anywhere. The code of conflict basically says "Your code will be criticized, deal with it. If you're subject to personal attacks, here's where you can complain." Note that Linus' infamous rants have always been direct criticisms of the code, so he won't be affected by this. The code doesn't promise anything more than "[resolution] of the issue to the best of their ability".

Comment: Re:When no one wants you to work for free... (Score 1) 255

by rdnetto (#49260557) Attached to: On Firing Open Source Community Members

The thing is, being an asshole shouldn't be relevant. Is the person contributing good code? That's all that should matter.

That only works if they're the only developer in the project. The moment you have more than one, there needs to be communication between them. This is compounded by the fact that nobody writes perfect code, so eventually that good code does need to be revised, and an arsehole who refuses to recognize the validity of other perspectives is an obstacle to that, especially if the reason it needs to be revised is that there is a core design fault.

Comment: Re:Write-only code. (Score 1) 757

by rdnetto (#49248409) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

When first announced here Rust looked very interesting, with some bold ideas for making programs better in the lower-level problem domain. Since then it's been under tons of development and community vigour, version 1 looked very different to 0.0.1, I need to reinvestigate!

I used it for a bit a while ago (0.9). It's a pretty nice alternative to C, but needing to explicitly deal with object lifetimes made it a bit too painful to be used as a high level language, which is a little ironic given the significant influence of Haskell in its design. There are ref counted pointers, but last I checked the syntax for them was pretty clunky. (An earlier version used a dedicated operator for them, but that got obsoleted. It's a shame, since that would have made it more usable as a high level language, similar to D.)

The final switch seems like it would be a useful construct. Python doesn't really have good Enums unfortunately, just some approximations such as using namedtuple._make(). Whereas in CoffeeScript you can assign the result of an if-else block to a variable, which allows for silly conditionals always a potential :)

Python has enums as of 3.4, though namedtuple._make() seems to resemble Haskell records more than a C-style enum.

Comment: Re:Write-only code. (Score 1) 757

by rdnetto (#49247529) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

IMO it's much cleaner to consider code as a series of transforms of varying kinds than a grab bag of tools.

I agree entirely - functional approaches tend to result in much more elegant code, where suitable.

I like Coffeescript's switch [coffeescript.org], but that's partly because I like having every construct being an expression, removing an element of the code/data divide.

That looks very similar to Rust's match construct, which is basically the same thing but with C-style syntax. Another useful feature I've seen (that would be incompatible with Python's preference for duck typing) is D's final switch, which ensures that cases exist for all members of an enum.

Comment: Re:Do it like the homestead act (Score 1) 115

by rdnetto (#49243167) Attached to: SpaceX Worried Fake Competitors Could Disrupt Its Space Internet Plan

Either commit to 100 percent coverage or accept that areas you're not providing service for should be able to use frequencies there that you use in other places but not there.

There's no reason to give someone that kind of blanket lease.

Allowing others to use the same frequencies in a compatible manner would achieve the same benefits (improved coverage, since anyone can operate a tower) without the fragmentation. Not to mention that the cost of negotiating spectrum rights in each state/area would be significant, to say nothing of the fun issues that crop up along boundaries.

What is more, the fragmentation is a technological problem that is quiet easily addressed.

First, we can have catalog frequency. That is one frequency EVERYWHERE that specifies what frequencies other services are using in the area. As your device moves it will periodically listen to that frequency and update its database for that area as to what is used by what. This ensures that every device will at least be aware of what frequencies are in use and by what.

You have now added a second antenna to the device, increasing power consumption and complexity, not to mention the additional logic needed to decode the messages.

Second, the next technological problem is making your device adaptable enough that it can shift to different frequencies and possibly even different protocols. Most devices already do this especially smartphones. My smartphone has a bluetooth radio, a wifi radio, an FM receiver, a GPS receiver, a 2G radio, a 3G radio, and a 4G radio. I think it can also handle either CDMA or GSM. So that is already a very wide range of frequencies and many different protocols.

While I could be wrong, I'm pretty sure the norm is to have different antennas for most of those. Bluetooth and wifi can share one as they use the same frequency, but 2.4 GHz is so far from 900/1800/2100 MHz that it would definitely need a separate antenna. Even making an antenna with the desired characteristics at 3 discrete frequencies likely increases the cost significantly - covering a continuous range of frequencies like that without degrading reception would be even harder.

Your idea is interesting, but ultimately overcomplicated. The entire thing is basically a hack to deal with the fragmentation introduced, but it appears to me your real problem is that the current system grants a monopoly over the frequency. This would be addressed in my proposal by mandating that anyone can use the frequency, provided they were compliant with the protocol and associated regulations. (Or to put it differently, the spectrum would be allocated to protocols, rather than corporations.) It's not clear at all what advantages your approach brings over this.

Comment: Re:Write-only code. (Score 1) 757

by rdnetto (#49242975) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

There should be one-- and preferably only one --obvious way to do it.

The problem with this rule is that it means limiting your feature-set so that you have N features with clearly defined regions of use, instead of 2N features with overlapping use cases. Switch statements are one example of this - they've been around since C (or possibly earlier) because they're clearer than a massive if-elseif-etc. statement, but Python lacks them, and people sometimes try to hack something similar into existence using dictionaries of lambdas.

Another is Python supports both functional and imperative programming, which means there's inherently two different ways of performing many simple tasks. Obviously many other languages chose only one of these, and Python is clearly more powerful for having both, but it's a good example of how having more than one way to do things results in a more expressive language.

Comment: Re:Write-only code. (Score 1) 757

by rdnetto (#49242901) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.

I disagree completely - I think the issue you're dealing with is that the kernel is not written in C++, and its style reflects that. The kernel is one of the best written pieces of C I've seen, easily better than an average C++ project. IMO, the only feature that the kernel would really benefit from is templates (for added type safety) - everything else works fine.

Furthermore, your argument about things being automatic in C++ is exactly the reason why most kernel developers use C instead! When you are writing a kernel, you absolutely do not want anything happening implicitly - it needs to be explicit, otherwise it's going to cause problems because it's not going to be obvious when it's interacting with something else. To give you an example, it's possible code in the block I/O subsystem to get stuck in an infinite loop upon allocating memory, since that request can result in paging, which results in disk operations via the block I/O subsystem, etc.

Context: I have experience doing both kernel programming (in C) and application development (in C++ with Qt). I think C++ is a powerful language which can lead to some rather beautiful code when used with Qt. I also think that C makes it far too easy to write bad code (buffer overflows, null terminated strings, needing to check return codes without defining a consistent scheme for whether 0 is success or failure, etc.). For any other project, I'd go with C++ in a heartbeat (or maybe D, depending on what libraries I needed). But in the context of kernel development, C++ is definitely the wrong tool for the job.

Comment: Re: Maybe in a different country (Score 1) 498

by rdnetto (#49240833) Attached to: Mental Health Experts Seek To Block the Paths To Suicide

For two reasons. The first is that in the majority of cases, depression tends to be the result of environmental factors, as opposed to genetic ones. The second is that many people who struggle with depression often have a lot to contribute to society, particularly as it is known to correlate with creativity.

Good day to avoid cops. Crawl to work.

Working...