I live in Iran and I am lucky enough to have a connected link right now, but this is the last link among the others I lost in the previous hours. I was wondering is there any stable solution like satellite internet or something without direct affiliation with government for people like me, desperate enough to ask questions like this.
It is based on Arabic script, but it has quite a few differences. There are a couple of extra consonants (گ چ پ ژ), some letters are different (ک vs ك), (ی vs ي), etc. Some letters simply do not exist in Persian (ڤ). There are quite a few differences between the two.
Fun fact: during the era of Windows 9x, Windows did not have good (any?) support for Persian, but it supported Arabic. Since Iran is not a signatory to any international copyright treaties, that was not a problem. A company in Iran called Borna Rayaneh essentially patched Windows 95 and later 98 to make it work with Persian. Their patched Windows version was ubiquitous in Iran. It would take a couple of years and Windows versions until Windows' default installation was good enough for everyday use.
Unfortunately Borna made some engineering decisions in making their version whose result has been a mess whose effects could still be felt almost a quarter century later.
In order to make things work for Persian, they took the Arabic version and tweaked it just enough to make it usable. One of the things they did was taking an Arabic font, removing glyphs that Persian did not have, and replacing them with glyphs it did. Remember, this was the pre-Unicode days. This was the easiest way to make it work, as opposed to creating a new encoding system. Their fonts (called series B, because their names all started with B) are still widely used today, and they are far from ideal.
For example, you open a document that has all ک encoded as ك. But the font shows it as ك, so you don't know anything is wrong. You search for a word with ک and it doesn't find any matches. And if you are a non-technical person, you get the impression that search doesn't work and start looking through the 582-page document manually to find the word you are looking for.
Normalizing Arabic and Persian code points (to the best of my knowledge by manual replacement of one with the other, not built-in standard library functions, because they are actually different and the only reason they are sometimes mixed up is historical decisions) is a must if you want to implement any sort of search in a website or an app.
> Since Iran is not a signatory to any international copyright treaties
Getting off from a tangent, how does that work? Your copyrights are ignored on any other country? Or do your people do something to get some kind of "international copyrights"?
I imagine it does not make much difference for patents, is that right?
> Your copyrights are ignored on any other country?
Essentially yes. If a work is produced outside of Iran, it does not have any copyright protection in Iran, vice versa.
As an example, since Harry Potter was quite popular in Iran, multiple (at least six IIRC) publishers translated it to Persian for the Iranian market. One publisher could not take another one's translated version and re-print it—the translated version was produced in Iran and enjoyed copyright protection in Iran. But the original English version was fair game for anyone.
Just in case it is not quite clear what Borna Rayaneh did to fonts to add Persian support: they essentially took Arabic fonts and wingdinged them until they looked Persian.
Also the sentence saying "But the font shows it as ك" should read "But the font shows it as ک".
Arabic has both, but they're pronounced differently from Farsi. (ي) is a (y) sound (like seed) whereas (ی) is either an (a) sound (like bat) or an (ay) sound (like may).
Not really. Arabic has U+0649 (Arabic Letter Alef Maksura), while Farsi has U+06CC (Arabic Letter Farsi Yeh). They look similar, even identical depending on the font, as long as they are standalone. When they are in a word though, it gets more complicated.
The important difference between U+0649 and U+06CC is how they look when they are connected to other letters. The former is always dotless. The latter is only dotless when it is not connected to another letter from the left. Here is an example:
U+0649 (Arabic): ى لى ىد لىد
U+06CC (Farsi): ی لی ید لید
It's kinda similar to how Turkish I's are not the same as English I's. English capital vs small form is different from the Turkish one, so different code points is necessary:
English: I i
Turkish (dotless): I ı
Turkish (dotted): İ i
Because Turkish uses separete letters for capital and small letters, only the different forms have their own codepoints. Because in Farsi and Arabic different forms of letters are implemented as ligatures, you need a different codepoint for each of them. You cannot reuse standalone U+0649 for U+06CC.
So to recap, Turkish has dotted İ and dotless I and they always retain their dot status. English has one I that will be written with or without a dot depending on how it is placed in the sentence.
Arabic has dotted ي and dotless ى and they always retain their dot status. Farsi has one ی that will be written with or without dots depending on how it is placed in the word.
Makes sense. Historically, all Arabic letters were dotless as you probably know. I wonder if this made it into Farsi script somehow, for this case at least.
The writing system is based on Arabic (with several extra letters, and several retained from Arabic used only in loanwords), but Persian is a completely different language.
People from Iran are from many different ethnicities, including Arabs [0]; although Arabs are one of the smaller ethnic minorities of Iran. Only about 60% of Iranians are Persian [1].
The preferred term for the language is “Persian”. The word for the language in the language (Like “English” in English or “español” in Spanish) is Farsi.
Ahamd from NetFreedom Pioneers, developers of Toosheh, here:
Toosheh is a satellite filecasting service. We transcode any digital data into a .TS/MPEG4 format and broadcast it over our satellite channel on YahSat over Iran and the Middle East.
Viewers of the Toosheh channel can record the broadcasting video and use Toosheh extractor on their android phone or PC to extract the transmitted content out of the recorded video. It's free, secure, untraceable, and most importantly the ONLY way to send digital files in case of total Internet Shutdown.
Toosheh is sending over 5Gigabytes of data over 2 hours.
Toosheh extractor software could also be used to browse a package of blocked websites that are blocked in Iran i.e. BBC, Radio Farda, etc..
Using Toosheh application people can locally share the content with others over WiFi.
If you think you could organize people quickly enough, maybe a meshnet? Or if you can get your hands on a few high-powered radios, you can transfer bits through them, though slowly, and you'd require cooperation from others (or just use them to talk with other people, but that's probably not what you're looking for).
Considering IRGC counter intelligence is likely constantly monitoring for radio signals it’s probably not a good idea to do so.
A mesh radio network could easily look like a cell of foreign tasked assets spying on the country especially if any of the peers would be near strategic POI’s.
In a western country you might pay a fine after clearing up a misunderstanding even if does get you pulled out of your bed in the middle of the night. In Iran on the other hand your fate will likely be quite different...
In the thread Toosheh is mentioned, a satellite filecasting service that operates in the middle east. It can be received with a regular TV satellite dish.
This is an interesting notion and one I never thought about before - there is nothing preventing another state from beaming internet down to citizens of Iran (or any other nation that shuts down internet but lacks technology to shoot down a satellite...
If Elon Musk was to put satellites over Iran, what kind of ground infrastructure would be required for someone to connect? Can it be a radio that fits in ones pocket but can easily be connected via USB or some other ubiquitous interface? The goal here is to have something so easy to hide and transport that the government can maybe find it from 50% of the population at best.
I used the same method to see what is the blocking mechanism in Iran. I tried to connect to www.bbc.com which is blocked in Iran.
The DNS injection is obviously in place. But something strange happened when I checked the SNI filtering. The curl command stopped at "TLSv1.2 (OUT), TLS alert, Client hello (1)" and never exited when I tried to connect to www.bbc.com but with a --connect-to that is not blocked. Nothing strange until now. If SNI blocking is in place, they probably drop all the remaining packets of the connection. The strange thing is that when I try the opposite test and I connect to www.kernel.org (not blocked in Iran, too!) but with www.bbc.com SNI it still stops at TLS client hello.
First I thought they blocked the IP address, but I was able to connect to 212.58.244.210 (the IP address of www.bbc.com) on port 443 with telnet command. So, is Iran's regime using some other blocking mechanism that I'm not aware of? Or am I doing some kind of mistake?
"HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates."
It is a dangerous mistake to decide what kind of privacy people need. Privacy should be absolute and without conditions.
What if you live in Iran? Some Ubuntu packages are already inaccessible due to government's pornography keywords censorship. E.g. I can't download "libjs-hooker" from this http link http://archive.ubuntu.com/ubuntu/pool/universe/n/node-hooker... from Iran. What if the government decides to censor the "tor" package?
I just finished reading this book yesterday. I am not an expert in refactoring but the book seems too old, although most advises could be still useful. Anyway, today I found a new book by the author: Brutal Refactoring: More Working Effectively with Legacy Code. Unfortunately, I couldn't find a good review of the book on the Internet. But I think it could be more useful.
Modern IDEs can deliver many of the recommendations of the book. Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc.
It was written for a different type of developer and a different type of development environment and a specific language, C++.
You haven't looked at C++ lately if you think it's the same as it was in 2004. The ISO has released new versions of the language in 2011, 2014 and ratified a new standard here in 2017. If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++.
Edit:
Modern C++ contains native support for the filesystem, threads, lambda expressions, variants, upcoming networking library, coroutines (at least in Visual Studio), no more new/delete memory management, parallel algorithms and a ton more. This is a completely different language now and the code you write looks nothing like 2004 C++ code.
Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc.
Just about all of these things were around in 2004.
"You haven't looked at C++ lately if you think it's the same as it was in 2004."
"If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++."
I applaud your attempt at an authoritative voice. But you focus on mostly technical trivia that are thin scaffolding on top of the language. I agree modern C++ is nice but it's the same language still.
"This is a completely different language now and the code you write looks nothing like 2004 C++ code."
Are you trolling? This reads like a transcript from a TV commercial.
They sound like they're echoing the kinds of things that are normally said about C++11.
> I agree modern C++ is nice but it's the same language still.
Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.
Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff.
I would say generally C++ style has evolved through last decades with people understanding class based architecture as an antipattern and data pipelines based on preferably immutable data as the more robust and understandable approach. This has nothing to do with language standards or 'idiomatic' constructs - both can be expressed as perfectly elegant C++, using the '98 or '11 or '17 variant.
But anyway, within this context -
refactoring old code - I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++. This is the main reason I find the claim of methods to understand circa 2004 C++ to be outdated to be silly.
> Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff.
That's never been the way that I've read it, and it's not how I meant it. New language constructs allow for more-natural ways for the code to express the intent of the programmer, replacing the use of older constructs in the places that they were clumsy.
The entire point is to make the language more practical. Patterns of use in a language aren't idiomatic because of dogma (or at least, they shouldn't be). They're idiomatic because they're a clear and elegant way (or at least the most elegant way available) to implement something.
> I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++.
Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017.
"Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017."
Well, if the original code is of the worst kind of a mess, Feather's circa 2004 collection of methods to make it more understandable but functionally the same work just fine for the first part of the refactoring. In my experience this is the most difficult part as well. To what dialect of the language the code is ported after it is understandable, is a relatively trivial syntax transform after this.
I speak from experience from having recently had to implement features to a production codebase with millions of lines of code, some of which date back to Fortran, and that took the final step of evolving into C++ sometimes in the late 90's.
I prefer the definition of legacy code that it's any code that does not have unit tests. In this case every transformation to a production codebase needs to retain the original behavior - without exact understanding what that behavior is.
I think this comment should have been my original response to this thread instead of the relatively cheeky responses I wrote earlier.
Intellisense (the MS one) was introduced in 1996. VB6 had good intellisense. I seem to remember having intellisense while working in classic asp vb (as in pre .Net), but could be wrong, it's so long ago now.
Modern IDEs can do many of the refactorings required when modifying code, yes. But you still need to know where to find seams or how to create them. Refactorings are just tools for getting there. It doesn't seem like you have read the book.
Me and a friend continually send IM's to each other, "LEAN ON THE COMPILER!".
That statement alone, one of the sections of the book, recommending you to allow the compiler to find your errors for you, is an example of the "age" of the book.
At the time I read it, when it first came out, I loved it. I still love Michael's work and advice to this day, but this book was written for another time.
I do not understand this. It seems like a perfectly good advice, and in fact it's what I'm doing every day - leaning on my compiler, and in Java world, on my IDE.
And also it seems to be something lots of programmers don't realize for some reason - many times I had to instruct people to crank up their compiler warning settings and actually read them. Especially in C-land, I can't count the number of times I solved someone's problem by appending -Wall to the gcc invocation and telling them to come back after they fixed all the warnings...
My point was that with a modern IDE we can do that without resorting to a full compile, which can be burdensome with large codebases.
The IDE space has improved a lot since 2004, eg. Jetbrains' tools around refactoring and code cleanup suggestions, make things super simple.
Don't get me wrong, I've read this book, multiple times, it's on my bookshelf and think it's a great book, but it was written when the state of development was a much different landscape, IMO.
Just looking at the responses to this comment, I have to say that I agree with both sides. The book is really dated, but the advice is timeless. The biggest problem I've had trying to get people to take the book seriously is that they can not identify with it. I had not realised that Michael Feathers had written a followup. I will definitely take a look. Thanks!!!
Moreover, SSH has stopped working, too. But, finally I found a way to circumvent it. A simple twist in the client side, could simply bypass the filtering.
I wrote a simple script to do this, and I would like to share it with all of my countrymen:
I took a look at it. It's not a binary. It's a python file (easily readable) that acts as a wrapper for ssh. Extract the contents of the tar.gz[1] for example to see it. It's great if it works because it apparently doesn't need changes to the remote ssh server.
No, it's not right. The GPL cannot "infect" Windows, so it's actually allowed (although I suppose what MS is saying is that if you think your license can infect Windows then it's not allowed, so it all depends on your interpretation).
The article does not make any sense, really. Especially this line:
>“If your app includes FOSS, it must not cause any non-FOSS Microsoft software to become subject to the terms of any FOSS license.” Although Microsoft didn't name it, it's talking about GPL.
Why would a GPL'ed app cause a non-FOSS software made by MS to become subject to the GPL? Does the app using the WinRT API cause the API to go under GPL?
Distributing VLC(even if by MS) does not cause the Win32 API used heavily by VLC to go under the GPL.
Distributing VLC(even if by MS) does not cause the Win32 API used heavily by VLC to go under the GPL.
There's an explicit exclusion in the GPL to allow linking against non-GPL "System Libraries", which does not include every closed-source library Microsoft has ever released. Even without the clause in question I doubt you'd ever be able to get a court to declare that Microsoft had to release the source to one of their non-Windows products because you tricked them into distributing a GPL application linked against it, but I can't really blame lawyers for being cautious in an untested area.
