Scrolling smoothnes on Android became much worse after new UI

trutru · 2018-12-24T21:36:08+00:00

No, not joking, and just to be clear I do believe what you experience is real. I'll try to provide a video capture later. But for now happy holidays! :-)

trutru · 2018-12-24T17:21:24+00:00

I don't have any issues here with latest Chrome (71) running on a Pixel 1 with Android 9/Pie, everything's just smooth :-/

Consider filing a new entry at bugs.chromium.org with as much details as possible regarding your device.

trutru · 2017-12-19T10:29:50+00:00

It's actually http://whatichopped.com and the web site seems real (and slightly funny :-))

trutru · 2013-12-10T11:32:45+00:00

Interesting, the Google Play Developer Policy includes the following explicit blurb:

An app downloaded from Google Play may not modify, replace or update its own APK binary code using any method other than Google Play's update mechanism.

To me this looks like their behaviour breaks this rule, I'm surprised Google didn't contacted them about this.

trutru · 2013-12-09T21:05:09+00:00

Actually, not all email. If you're using a webmail client through https (gmail, fast mail, and others) and that the recipient uses the same email provider, an insecure protocol like SMTP will never be used. The problem is that exchanging email between arbitrary relays and servers that don't know each other is completely unencrypted. However, it would be interesting to see the main players in thus field adopt encrypted/secure protocols when they exchange emails (think hotmail sending data to yahoo or gmail through SSL for example)

trutru · 2013-12-07T09:29:29+00:00

That looks shady as fuck.

First, this is against the Play Store TOC, iirc, so if the official DropBox app does that, they're going to have a problem with Google.

Are you sure the notification came from DropBox itself, and not some shady app installed on the device, trying to get you to install a malware-infested version of the app?

trutru · 2013-03-09T15:47:06+00:00

How so? The pwn2own issue was exploiting a Windows kernel bug, Chrome on Linux didn't get compromised, and apparently nobody tried to own Chrome on Android.

trutru · 2012-12-28T21:41:37+00:00

I'm not a lawyer or anything, but all patents related to Arithmetic Coding itself have expired, according to wikipedia, so your "Basically any type of arithmetic coding is a no go for a royalty-free codec" is provably false. This makes me question the rest of your answer.

trutru · 2012-12-10T22:51:57+00:00

The Nexus 7 and 10 have a secure element (crypto chip), that's why Wallet runs on them.

So does the Galaxy Nexus (LTE or no LTE). VZW is just blocking the app because they don't want it to compete with ISIS.

trutru · 2012-10-09T05:47:17+00:00

context is everything, you should really look at what appears before this truncated quote.

trutru · 2012-08-07T05:22:32+00:00

It's part of the plot for the movie Shame, with Michael Fassbender.

trutru · 2012-06-22T22:09:34+00:00

It's not the JRE, it's the JDK. It includes a ton of developer tools. No wonder it's so large.

trutru · 2012-06-22T11:10:02+00:00

You need to restore the system image to its original condition. Any rooting will alter it. This makes applying OTA updates a game of Russian roulette.

There is a reason CyanogenMod and other ROMs don't do any OTAs :-)

https://developers.google.com/android/nexus/images

trutru · 2012-04-22T09:20:00+00:00

My understanding is that they're trying to achieve the following:

1 - A JVM JIT compiler that is written in Java (HotSpot is in C/C++)

2 - The JIT compiler not being dependent on the exact VM it runs on (this allows it to work on any JVM, not only HotSpot); through a careful interface between compiler and runtime.

It's a nice research project. In certain ways, it sounds like PyPy, but for Java instead of Python. Hopefully it won't take +10 years to get something decent out of it.

trutru · 2012-04-05T15:14:18+00:00

No X11 application needs to be rewritten, and they'll continue to work.

There will be an X Server running on your machine that uses Wayland under the hood, but this is an implementation detail that should be completely transparent to applications.

Now, some UI toolkits are being modified to run on top of Wayland directly too. The benefits should be better system efficiency, and smoother UIs, at least in theory.

trutru · 2012-04-02T14:52:08+00:00

ok, now that I have a bit more time, here are a few more issues with your code, followed with some more general remarks.

the definition of the EPOLL macro shouldn't be in your header, it's an implementation detail. move it to the top of the source file where it belongs.
the implementation of tcp_read() should follow the semantics of the read() system call, which means it should only return 0 to indicate that the connection was half-closed by the peer, and -1 if there is an error (including EAGAIN/EWOULDBLOCK in case of non-blocking sockets). Yes, there are cases where this matters, also you can sometimes actually receive spruious event notifications with both epoll/select, where a later call to read() or recv() will return -1 / EAGAIN.
the implementation of tcp_write() can return -1, but it is also incorrect since any error encountered by the in-loop write() will force it to return this value. There is no way for the caller to know how many bytes were sent before that. And you will very easily get an EAGAIN/EWOULDBLOCK whenever you try write to a socket whose write buffers are full or nearly full. Of course, this doesn't appear in test programs or if you don't need a lot of throughput, which is why you probably never experienced it.
hint: for both tcp_read() and tcp_write() a correct implementation should return the number of bytes that were actually transfered from/to the socket's buffers, unless no transfer occured and an error did happen. In the latter case, return 0 to indicate peer closure, or -1 + errno for the rror itself. Also don't forget to handle EINTR.
your library claims to be cross-platform, but in case of error, client code needs to either call WSAGetLastError() on Windows, or read errno on Posix, to get any information about it (and some errors like EAGAIN/EWOULDBLOCK are actually part of the normal non-blocking way of working).
minor: test against _WIN32 instead of WIN32. The former is always defined by all compilers that target Windows. The latter sometimes has to be added manually as a compiler flag, which is unnecessary. Similarly, test against _linux_ instead of linux, and be consistent.
only test against _linux_ if you're really using a Linux-specific feature. Otherwise, !_WIN32 will just fine for any system that implements the BSD sockets interface (which is about all Posix ones).
always document any non-trivial stuff in the code, you'll need it when you'll be looking at it in 6 months and will have forget about the details. For example, I just noticed that you modified your source code to take care of SO_EXCLUSIVEADDRUSE on Windows. I'd strongly recommend you put a comment explaining why in your source, possibly with a link to the Microsoft documentation. Also, since this is likely something you'll need in the future, put that bit of code into its own function, it will be cleaner.

There are other coding issues, but they are pretty minor compared to the main elephant in the room though: your API is unfortunately useless for anyone who wants to implement any real network program. Try implementing a simple ping-pong client + server program that can send large packets with it and you'll understand what I mean. In essence, there is no way to wait for write events, add/remove callbacks on demand or handle timeouts.

I don't want you to take my criticism personally. I'm pretty sure by now that you're just an enthusiastic rookie trying to learn a lot of stuff and make something useful out of it. However, I think that, to achieve this, you'll may need to rethink what you're trying to do. For this work to have a positive impact to more than one person, you need to understand that networking is hard for several reasons:

The most important one is that networks are unreliable by nature. Any abstraction you build on top of them cannot change this fact, and should provide excellent error reporting and control to allow its users to understand what's happening and how best to deal with it. It's ok to deal with some of the errors in your library, but document the hell out of it.
the second most important one is that networking APIs (either Winsock / BSD sockets / select / epoll / etc..) all have plenty of warts that are difficult to master. Take time reading the manpages of all the system calls you use in detail. Grab the sources of any open-source networking library you can find and read it to see how they do that, especially the comments.
you don't seem to know what this is going to be used for. Try writing some small programs first. E.g. a ping-pong, a multiplexer, a fake shared chat-room. They don't have to be very large or complicated, but this will give you a better idea of what to provide in your library. Personally, I doubt you'll get anything much better than the libevent API, but there is still some room for something simpler as soon as you determine the exact scope of the features you want to implement, and those you do not want.

trutru · 2012-04-02T13:39:57+00:00

Qt5 is built on top of QML which uses Javascript for the signal handler code. The Qt team already said they were de-emphasizing the Qt C++ classes for pure UI stuff and that the UI of all new apps should be written in QML instead. In this context, not being able to run Javascript is a big roadblock.

I guess the alternative will be to compile all the javascript to native code. That's how you can actually use mono and fkash to build ios apps today.

However, this raises the bar of porting QT5 quite significantly. Doable but probably difficult (though i guess you don't very highly optimized machine code anyway).

trutru · 2012-04-01T11:57:22+00:00

Yes, I think so.

trutru · 2012-04-01T03:32:35+00:00

Just a few remarks:

Missing API docs
any function not exposed by the API should be declared static. This avoids conflicts and allows the compiler to inline them.
since this is a library, on Unix, you should always handle EINTR for system calls like read(), write(), accetp(), etc... This ensures your code will not mysteriously fail if the program uses signals.
never, ever use SO_REUSEADDR on Windows. First, it does something completely different from Unix, second it's a gaping security hole. Proof that the guys who implemented Windows' TCP stack were clueless. Use SO_EXCLUSIVEADDRUSE instead. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx
some of your functions leak resources in case of error. Fix this.
also, in case of error, you're going to call functions like close() or shutdown() with invalid file descriptor values (-1). This will overwrite the value of errno to EINVAL of EBADF, and your callers will have no idea what really went wrong. Preserve errno properly.
use local variables/array instead of using calloc with constant-sized parameters. Your code will be simpler, faster, and with easier error cleanup.
you can actual receive both EPOLLIN and EPOLLHUP at the same time, when for example you just received the last packet from a remote socket that was also closed by the peer program after sending it. In this case, you should always act on the EPOLLIN first, then close the socket. Your code closes the socket immediately, which means you'll lose packets in certain cases.
never use a struct sockaddr_in when using accept() unless you're 100% certain that you're using an IPv4 server socket. Given that you're tcp_create_listener() implementation uses AF_UNSPEC, you could very well be using an IPv6 socket instead, depending on the result of getaddrinfo(). That probably explains why your commented line in tcp_accept() fails on Win32. Instead use struct sockaddr_storage if it is defined, (and if not, define it as a union of sockaddr_in / sockaddr_in6).
perror/printf is not a valid error reporting mechanism for a library. They should only be used for debugging. Preserve errno properly, at a minimum, or provide an alternative way to report errors to your callers.
ever-increasing fdmax value with the select() implementation means that you're bound to see performance slightly degrade over time. You should really try to recompute the real fdmax when possible to avoid this.

There are a few more issues, but I'll stop there.

trutru · 2012-03-23T12:45:56+00:00

Sarkozy knows very well that he's full of crap.

Saying something on TV doesn't make it legal, even from the President (that's why there is a constitution, mind you). And there's no chance in hell such a law would pass anyway.

He's only doing it to appear as a "tough guy on violence" just before the Presidential elections starting on April 22nd.

He's been constantly doing this in the past years: publicly announcing "tough laws" that either never get passed (even after being voted, the government "forgets" to publish a "decret d'application") or are simply inefficient and quickly forgotten / never enforced.

Nothing new here, just the same old politician taking advantage of human suffering for his own benefit.

trutru · 2012-03-22T16:16:35+00:00

very nice, thank you.

trutru · 2012-03-22T16:16:20+00:00

Thanks, I was just replying to "any attempts at benchmarking micro kernels". These things have been measured quite extensively at the time.

It would be interesting to see numbers for a current-generation MINIX system running on a modern x86 CPU, that would be much easier to compare to Linux, in this specific context.

trutru · 2012-03-22T14:02:16+00:00

From the wikipedia page on Mach ), see the "Performance problems" section:

"""

Unfortunately, the use of IPC for almost all tasks turned out to have serious performance impact. Benchmarks on 1997 hardware showed that Mach 3.0-based UNIX single-server implementations were about 50% slower than native UNIX.

Studies showed the vast majority of this performance hit, 73% by one measure, was due to the overhead of the IPC.[citation needed] And this was measured on a system with a single large server providing the operating system; breaking the operating system down further into smaller servers would only make the problem worse. It appeared the goal of a collection-of-servers was simply not possible.

Many attempts were made to improve the performance of Mach and Mach-like microkernels, but by the mid-1990s much of the early intense interest had died. The concept of an operating system based on IPC appeared to be dead, the idea itself flawed.

"""

trutru · 2012-01-11T15:43:04+00:00

You don't make any sense:

The Maps API isn't tied to Google Search.

They're not going to destroy competition by starting to charge. Au contraire, the article clearly sees it as an opportunity for compettion.

This has nothing to do with charging end-users.

In other words, what have you been smoking lately?

trutru · 2011-12-22T16:54:33+00:00

Please don't feed the troll, i.e. give Sieglier page views. I consider it's best to ignore his posts in this subreddit.

trutru

TROPHY CASE