After upgrading to Kubuntu 18.10, my virtual machine was no longer able to connect to the Internet. It turned out that this problem had already been reported on Fedora:
Once I changed the firewalld configuration (etc/firewalld/firewalld.conf) to use the iptables backend as suggested in that bug report, the virtual machine could connect to the Internet again.
I upgraded a desktop machine from Debian Squeeze to Debian Wheezy. After the upgrade, the power button was mapped to a suspend action, instead of a shutdown as in Debian Squeeze.
In order to map the power button to a shutdown action, I had to do the following;
'nothing' by means of dconf (for all users)
2) Add a new section
[org.gnome.settings-daemon.plugins.power] with the line
I’ve come across several posts on the Net that states that concatenation of MP4 files by means of MP4Box (from gpac) will make VLC play two videos concurrently instead of playing the videos in sequence.
I had the same problem, but once I had all the source MP4 videos generated with the exact same audio and video encoding parameters (that meant adding audio to the MP4 videos that did not have audio) things worked out fine.
Actually, I thought I had used the same parameters for all my MP4 files, but during the conversion from an AVCHD video to an MP4 by means of ffmpeg, the frame rate somehow went from 25 fps to 26.09 fps (you can check this using
ffmpeg -i somevideo.mp4 on all your MP4 videos). Once I added “-r 25” as the last option to ffmpeg, the issue was resolved.
I’ve recently had a deja-vu while reviewing a proprietary application level protocol; the protocol wasn’t robust with respect to loss of the connection at the transport layer. The reason for this was a design flaw I’ve seen before.
The proprietary protocol relied on a positive acknowledgement transport protocol (like TCP/IP) to ensure that unacknowledged packets got retransmitted. However, lost packets are typically not retransmitted indefinitely. TCP/IP protocol stacks, for example, only try to retransmit unacknowledged packets a limited number of times before aborting the connection.
So, if a connection breaks, how much data can a sender assume that the reciever actual got? Not much, actually. Lack of a positive acknowledgement of a packet could mean that the receiver never got the packet. However, it could also mean that the receiver actually got the packet, but the acknowledgement was somehow lost on its way back to the sender. A broken connection may therefore potentially leave the state of the two peers out-of-synch. When the transport layers become ready to exchange data again, the application layers must somehow be able to continue their protocol without knowing each others precise state.
The best strategy to cope with this problem depends on the problem domain/protocol. Retransmission of the last PDU may be one option, but it will require that the protocol can cope with duplicate PDU’s. Another solution (but often more involved) would be to have the application level protocol let peers probe each others state before continuing normal protocol flow.
Much the same conclusions can be drawn for negative acknowledgement protocols, by the way.
I’ve just released version 0.2.0 of tds2dbg. The new version is now able to insert debug information for public symbols as well as source code references (file and line number) in the dbg files. See http://www.ohloh.net/p/tds2dbg for more information.
Some time ago, I published tds2dbg – a small command line tool that converts Borland debug symbol files (*.tds) to Microsoft debug symbol files (*.dbg). See more on http://tds2dbg.sourceforge.net/
The tool was created while doing consultancy for one of my customers, but the customer was not too keen on maintaining it after I left. We therefore agreed to make it open source.